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
<http://code.google.com/p/tarantino/wiki/DatabaseChangeManagement>I've never used it personally but it sounds like it covers what I'd want to be doing anyway. The hardest requirement is that each script needs a number to keep them applied in the correct order. In reality this just means that devs on the team need to communicate when they want to change the db which isn't a terrible thing. On Mon, May 31, 2010 at 10:32 AM, noonie <[email protected]> wrote: > 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 name resolution means that some > warnings like 04151 "...has an unresolved reference to object..." equate to > runtime errors in the real code world. (it is amazing how many concepts > cross-over into the db world with the latest tools from Microsoft). > > If not then I would seriously recommend that you invest the time in > developing an automated build & deploy method so you can "prove" the > database before rolling the scripts out. > > -- > Regards, > noonie > > > > > > > > On 31 May 2010 11:14, Greg Keogh <[email protected]> wrote: > >> 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 script to >> the source controlled file whenever it’s changed. >> >> >> >> Because scripts aren’t compiled source code, there is still the risk of >> human error in not pushing any updated script files into the DB. I was >> thinking of concocting a utility which automatically pushed changed scripts >> into the DB, but before I start fiddling I thought I’d ask about this >> subject in general first. Are there others out there who source control >> their DB scripts and have techniques for reducing human error? Or perhaps >> there are better techniques that I’ve completely overlooked. >> >> >> >> Greg >> > > -- Michael M. Minutillo Indiscriminate Information Sponge Blog: http://wolfbyte-net.blogspot.com
