Some javascript/style in this post has been disabled (
why?)
Mike,
The way I approach this is to provide an extra feature to
install the database scripts using the various "defaults", but always
to install the database scripts and installation options whether or not that
feature is requested. Alternatively, I provide a "Database
scripts" feature and a child "Install the database scripts"
feature. A number of corporations have exactly the same beef you do, but
we can't just fall back to requiring DBAs to edit scripts.
The real problem with SQL scripts is their lack of a decent
conditional execution environment. Sure, you can code the scripts with
"sp_executesql" all over the place. This loses all the nice
editor support available for SQL. So, because CREATE PROCEDURE must
be the only statement in a batch, you lose conditional creation.
Bah! Even with all this, you can't even get arguments into the damn SQL
scripts in a simple-to-use way that is also standard across execution
environments. It's insane that people still have to write their own code
to separate SQL scripts into GO-keyword-separated batches.
We really need a standard SQL installer framework that does the
following things:
·
Create a database
·
Create each schema object
·
Upgrade each schema object if it already exists
If there was a standard pattern (or better yet, library) to do this,
then all the things you bring up could be addressed in this framework.
jmr
From:
[hidden email]
[mailto:[hidden email]] On Behalf Of Mike
Dimmick
Sent: Friday, May 16, 2008 11:30 PM
To: 'Tanikella, Rajanikanth (SCR US)'; [hidden email]
Subject: Re: [WiX-users] yep - back to being 100% frustrated
...cut...
With my database administrator’s hat on, I find applications
that install their own databases tiresome. They inevitably seem to make
mistakes in their installers. Reporting Services service packs don’t
quite line up with schema versions, so you seem to end up scrapping the
existing database and recreating. SourceGear’s Vault accidentally
inserted a backslash before the data file name when there was already one at
the end of the path, then SQL Server’s Volume Shadow Copy Writer
complained when trying to back that database up. Other tools don’t give
the administrator the option of where to place the database – any
sensible SQL Server setup (not dedicated to a single database) will want to
place the data files on a disk separate from any other files, and the log files
on further separate disks, so the ‘default’ DB location may well
not be useful. Given the amount of flexibility required, you may well want to
just supply scripts and allow the DBA to run them after creating databases
themselves, and that’s the approach we’re taking (the application
server supports server farms with a SQL Server database for shared state).
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________
WiX-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-users
