Re: Source control of DB scripts

> > *From:* ozdotnet-boun...@ozdotnet.com [mailto: > ozdotnet-boun...@ozdotnet.com] *On Behalf Of *Jano Petras > *Sent:* Tuesday, 1 June 2010 8:15 AM > *To:* ozDotNet > *Subject:* Re: Source control of DB scripts > > > > Greg, > > An approach that worked well

RE: Source control of DB scripts

From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Jano Petras Sent: Tuesday, 1 June 2010 8:15 AM To: ozDotNet Subject: Re: Source control of DB scripts Greg, An approach that worked well in the past for me was: * No permission to execute DDL

Re: Source control of DB scripts

Greg, An approach that worked well in the past for me was: * No permission to execute DDL statements on staging / dev databases given to the developers. They still have full access to their local copies. * All database updates (tables, SPs, population scripts etc) are to be checked into source

Re: Source control of DB scripts

Hi Greg, I use MigratorDotNet to address this issue. Migrator allows me to define incremental changes to the database using code, which is then checked into source control along with everything else. We have a Continuous Integration setup, and when a bu

Re: Source control of DB scripts

There are a number of tools to manage the CI side of things for you. The one whose name I always remember is Tarantino http://code.google.com/p/tarantino/wiki/DatabaseChangeManagement I've never used it personally but it sounds like

Re: Source control of DB scripts

Greg, If you have a VS 2010 Licence (or at least VSTS 2008 with the Data Dude GDR2) then you can keep the database projects in source control and also get some pretty nifty error checking to cut down on those "stupid" errors by using database projects. Just remember that SQL Server's deferred nam

Re: Source control of DB scripts

Hi Greg, I've worked on a project which has done the scripts in source control approach. I think the thing which made it work was that part of the CI build was to actually spin up a new db and run all the scripts. Failure of the scripts to run triggered a build failure and appropriate blame placed

Re: Source control of DB scripts

Poor mans approach is to version the updates and version the database. (Im sure theres way more sophisticated tools that would do all this form you mayby like dbghost etc) So in your update script you may have something like SET @CurrentVer = (Select dbschemaVersion from ControlTable) If @Curren

Source control of DB scripts

Folks, I'm sure we've all had problems where multiple developers change SQL Server scripts and they get out of whack and waste time with stupid errors. I'm starting a fresh app and I thought I'd experiment with keeping scripts in SVN. It just means that we have to remember to always save a scri