SQL Server version control? 1

[karen4201]

I'd like to apply the principles of Version Control to my database objects. How are others doing this?

I am thinking about saving the db scripts as text files and then using a version control program to organize and manage the text files. However, this puts a requirement on any database administrator to correctly check-out and check-in any files they've changed. Even though the text files will maintain a "state" of the db, the lack of version enforcement could cause problems.

Any suggestions are greatly appreciated.

 

[123FakeSt]

For real time version control I would imagine that you would need to spend some money.

A cheap solution I have used to do this was to get CVS version control, then schedule a DTS package to write all of your recently modified database objects to a script repositiory in CVS. Though any rollbacks will have to be done manually.


The early bird gets the worm, but the second mouse gets the cheese.

 

[druer]

All SQL objects are inheritantly just plain ASCII text. So any version control is fine. In the past I've used Visual Source Safe, but there are also other tools that integrate into Visual Studio to make things easy.

I think that with SQL Server 2005 you could have alerts put in place when objects like Tables, Stored procedures change and can have someone use those alerts to audit the DBA but you are always going to be at the mercy of the DBA to either use it or not use it. While products like Visual Source Safe can control a programmers interface to the code, the system administrator if they wanted could change the source code at the file level without the interface so you are also dependant on them in environments where they might also be a programmer. So that "trust" is nothing new.

 

[karen4201]

Yeah, I was thinking about using VSS or CVS and do versioning of the text scripts for the database objects. I'm glad to see that other people think the same things

Thanks!