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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Dimmick
Sent: Friday, May 16, 2008 11:30 PM
To: 'Tanikella, Rajanikanth (SCR US)'; wix-users@lists.sourceforge.net
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
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
