This may not be a MSSQL-specific question, but
I wanted to ask it here first, in case there's
a MSSQL and/or SourceSafe solution that will help.

Our dev team is having some difficulty with
keeping the nightly builds in sync with the
stored proc mods. I'm wondering if there are
some good case studies on how to avoid this
"drift". Something like genning a new DB from
checked-in SPs, etc. alongside each regular build,
then always have a paired enterprise app/database
duo that is tagged and added to a history.

FWIW, we have a 3-tier .NET/C# app, and
ADO.NET is throwing exceptions every other
day.

If the suggestion is to whip the DB guys, that
works for me as well. ;-)

Nah, there's much love there.

Thanks in advance,
~swooz

We keep all of our DDL scripts under source control. These are labeled and
built along with the app code as part of an installer custom action. We
promote all stored procedures, views, and functions along with the rest of
the app so the interfaces don't get out of sync as long as the checked-in
code is correct.

Our database installer allows either a new our upgrade installation. Even
if the 'new' install isn't needed for production, it facilitates testing
since it's the 'gold' database schema. We also include upgrade capability
as needed for production releases. The bottom line is that new and upgraded
schema are identical.

--
Hope this helps.

Dan Guzman
SQL Server MVP

"swoozie" <swooziep (AT) yahoo (DOT) com> wrote

We use a product called DB Ghost to build our SQL Server databases
directly from SourceSafe every 10 minutes. A script checks the report
it produces for any errors and automatically emails all of the DBAs and
Development team if any are found. This covers any syntax or
dependency issues with checked in code.

If everything builds OK DB Ghost is then used to produce an upgrade
script against a restored copy of our test database. If this fails the
problem is emailed out and fixed there and then. The test database
copy is then restored again and the compare rerun - if it works then we
have a delta script that we can run in Query Analyzer against our real
test database. This same approach is used all the way to production.
The script produced also works first time - I've used other products
before but none of them come close to producing a working delta script
in the first run - I always had to correct object dependency problems
manually in Query Analyzer first.

The real beauty of this is that we only keep the delta script produced
by our overnight build which starts from a labelled baseline of all
code in VSS. This means that our SQL Code is 100% in line with our
VB6/.NET and ASP code every single time we do a release. Sure, it
doesn't get around the problem of developers not checking their changes
in properly but it does give us a great audit trail which means we get
to the root causes of those tricky test database problems real quick.

We are even thinking of losing the delta script altogether and just
letting DB Ghost do the upgrade dynamically, that way our baselined,
labelled scripts in VSS are the real 'source database' - this is
totally cool stuff.