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 >
