Micorosoft, since the release fo MSDE Rel A, the very first free edition for
everyone, 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
if you run out of instances, you won't be able to install a new one...
of course there are implications running several SQL Server instances, as
each of them will consume resources... each of them will be loaded into
memory, but this is not to say that each instance adds the very same
footprint, but they can quickly contend for system resources on heavy loaded
actually this is the path you should follow, if no compelling reasons for a
private instance exist...
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 [email protected]
so you can previously collect all required/desired information you need and
pass them on...
under MSDE time frame I personally provided a "companion" boostrap installer
of MSDE to collect all required info and shelling then to the actual
setup.exe providing all gathered parameters as commandlind params...
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
install the engine only on the machine that will act as "the server".. you
are used to SQL Server already, so keep this in mind...
another story is when and if you decide to use a SQLExpress available only
feature known as User Instance (RANU),
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...
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"...
this setup can include (or not, depending on your design you can put that in
an additional companion tool of your app) the physical database(s)
installation procedure, task I do perform with something similar to
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...
all this, obviously, IMVHO....