Forum Moderators: open

Message Too Old, No Replies

Version control of SQL Server database

Managing change of source code is fine, but what about the database?

         

bhonda

10:01 am on Mar 18, 2009 (gmt 0)

10+ Year Member



Hey guys,

Just a quick question - what is the common practice to control changes and versions of databases? The way to maintain versions and changes of source code is fine (with the whole checking/in-checking out process, amongst others) but how would a database be managed for changes such as table structure, stored procedures, etc?

Any help would be greatly appreciated!

Cheers,

B

Ocean10000

3:31 pm on Mar 18, 2009 (gmt 0)

WebmasterWorld Senior Member 10+ Year Member Top Contributors Of The Month



The way I currently do it for my own sanity.

I wrote a bit of code to do an schema export of the database in question. And check in this report with the other related changes. While this doesn't cover all the issues, that exists. It does at least give you an idea about structural changes made in the database. The trick is to make sure that the report is structured in a way that you can easily use diff tools on the versions to see the changes. Most tools will output the schema in what ever order the database returns it in, which will vary on every export I have found.

The other part of this is when making changes to the database is to save all the sql change scripts, in the order that they were done, so you can repeat the process on the live servers, or redo the test servers if you have to restore to a previous point. I currently do not check these in, but are made part of my rollout process, and saved as part of the build for future reference.