What options are available for running Source Control in SQL Server 2005/2008?

What software is available to enable Source Control in SQL Server 2005 and later. What are the disadvantages of using Source Control in SQL Server, if any?

0


a source to share


4 answers


Well, it depends on how you want to do it. You can use Visual Studio 2005/2008 to create database projects that will generate all the scripts you need to create your database. Then you can test the scripts in any source control system you like.

Toad also has a " command encoding " that allows you to use toads as your version control system.



I highly recommend that you get used to using version control for your databases. Some of the benefits are highlighted by Jeff Atwood in his articles, "Is Your Database Version Controlled?" and "Get my database under version control" . I have used this method with MSSQL and visual studio databases to version control my databases.

+3


a source


I prefer not to manage the source code of the database itself, but the scripts I use to create the database. I am using Visual Studio Database Edition (which is now available as part of the developer edition).



Essentially, the tool stores all the creation scripts in the original control, but then you can create scripts that will update the database according to the project. It works really well.

+1


a source


This is a difficult task to solve. Since most of the databases I work with are bound to a specific application in Visual Studio (YMMV), I usually do this: after starting development, I generate a "create database" script just for the schema and put it as a .sql script in some then parts of my application. I am including a function in SQL Management Studio that prompts me to create a change script every time I change a table or stored procedure or whatever you have ... so whenever I change something I save the script change and add this towards the end of my original "create" script. This way anyone can hijack the SQL script and completely generate a fresh copy of the database up to where the trunk is.

It's primitive and needs more control, keeping database changes in sync with the version of the app that hits it, but that's better than nothing for me. I would be interested to hear if there are original control solutions that integrate more cleanly.

+1


a source


built-in source control in SSMS allows script processing; it will not track changes directly to your database.

Personally, I use ScriptDB to automatically generate separate scripts for my entire DB, which is then a source of control through Visual Studio - as I validate my application code, it validates those SQL scripts as well. I also script any changes to the DB explicitly - they are used to update production servers over time - and they are also source-driven via VS.

Pretty much everyone I have come across uses a similar technique, if they do anything at all. Many don't.

0


a source







All Articles