Re: Recommended Approach for deploying SQL Server Express with shrink wrap software
- From: "Troy Wolbrink" <wolbrink@xxxxxxxx>
- Date: Sun, 19 Feb 2006 15:23:33 -0500
MS ... no longer recommends to set up a private instance for each ISV
untill such a circumstance is strictly required (say particular
collation/sort order requirements, or privacy matters or the like...)
SQLExpress stresses this rule suggesting a "common instance" named
\SQLExpress, and, if you're not compelled for other reasons, you should
install such a common instance or take advantege of it, if already
present...
This sounds like a reasonable way to go. Might someone be able to point me
to where this is offiically documented by MS?
What is the recommended approach for installing ...
the SQLExpress bootstrap installer includes an UI to perform personal
settings, or you can provide your own setup gui and provide all required
parameters to the setup.exe bootstrap installer, say, for instance,
"setup.exe /qb INSTANCENAME=SQLExpress SAPWD=@123456789o SECURITYMODE=SQL
...
Like you, I've written a simple program to shell command-line arguments to
help our IT staff to install MSDE, and I'm very comforable and familiar with
this aspect of the installation. But in a different context, where this
installation is performed by the masses, it must be transparent. It would
be pointless to ask users what they'd like for the "sa" password or what the
"securitymode" should be! So what are the recommended way to install the
common "SQLServer" instance (ie. "sa" password, security mode, disable
network protocols, etc.)?
again, consider that, usually, even on a little lan, you will not install
the engine on each machine basis as you do for your application(s), but
you
Of course, and my installation program would provide an "Advanced Settings"
area where the setup could be completely customized for the more unique
cases like this.
another story is when and if you decide to use a SQLExpress available only
feature known as User Instance (RANU),
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsse/html/sqlexpuserinst.asp
..
this can be convenient in some scenarios for ease of use and maintenance,
but, of course, should not be used in multi-machine/multi-user ones...
I read that article, and it actually raises the point that normal users
running as non-Administrators can't attach database files ad hoc to their
local server, unless using User Instances. A MAJOR reason for using SQL
Server Express is to allow merge replication subscriptions over the
internet/https. But the article mentions that not being able to use
replication is a limitation of User Instances. So I either have to require
users run as Administrators (bad idea), give up on using replication
features (and thus the whole point of switching to SQL Server 2005), or I
need a way for my program (but not users) to know the "sa" password (sounds
like an impossible security issue). Perhaps this is a reason for me to
install my own instance (or to stay with JET!).
personally I'll continue providing a separate setup path, 1 setup for
application(s) that must be executed on each machine and 1 setup (actually
the SQLExpress setup) for the engine itself, to be executed on the machine
acting as "the server"...
Sounds great in a non-shrink-wrap deployment environment. I'd really be
stretching many of my users to tell them "run this setup on the machine
which acts as the server", and "run this on all the client machines". I can
appreciate how much this helps IT staff to get things going, but it's still
to technical for my users.
...
installation procedure, task I do perform with something similar to
http://msdn.microsoft.com/msdnmag/issues/04/09/customdatabaseinstaller/ I
already produced since 1999 ( :-D )
in my case, it's a separate companion tool that is used to perform both
initial installation of the database(s) and successive (eventual)
database(s) upgrade... I do strongly like this path as it support both
tasks and even include ability to maintain db design under source code
control for histroy and management...
I've also been using a strategy just like this. I keep a database structure
version that I can read out of any of my databases, and I have scripts than
can "upgrade" the database if need be. The scripts are part of my
application, and are kept in Source Safe.
By the way, this is getting more and more complicated, so does staying with
JET and starting to use JET Replication seem like a bad or good idea?
Choosing it back in 1999 was a very successful move for me, and has given my
development/deployment environment alot of simplicity. I really love how
the entire database is kept in one file and deployment is practically
trivial. I'm starting to wonder if the benefits of porting my app to SQL
Server and using all its new shiny features are enough to outweigh the added
complexity of trying to use SQL Server to emulate a file-based application
(in a way that is perfectly natural for Jet).
--Troy
.
- References:
- Recommended Approach for deploying SQL Server Express with shrink wrap software
- From: Troy Wolbrink
- Recommended Approach for deploying SQL Server Express with shrink wrap software
- Prev by Date: Re: Stored Procedure Question
- Next by Date: Re: Installation
- Previous by thread: Recommended Approach for deploying SQL Server Express with shrink wrap software
- Next by thread: Re: Recommended Approach for deploying SQL Server Express with shrink wrap software
- Index(es):
Relevant Pages
|
Loading
