What is the best way to version control my SQL server stored procedures?

Question

What is the best way to version control my database objects? I'm using Visual studio 2005/2008 and SQL server 2005. I would prefer a solution which can be used with SVN.

Solution 1

Same as your other code, add a "Database project" to your application solution and keep the sql files used to build the database objects in there. Use the same version control for those code files as you do for the application.

Solution 2

Look at the tools offered by RedGate. They specifically deal with backup / restore / comparison cases for SQL Server objects including SP's. Alternately I am not sure but I think that Visual Studio allows you to check sp's into a repository. Havent tried that myself. But I can recommend RedGate tools. They have saved me a ton of trouble

Solution 3

I use SVN for all of my table/sproc/function source control.

I couldn't find anything that met my needs so I ended up writing a utility to allow me to dump the code out into a nice directory structure to use with SVN.

For those interested, the source is now available at svn://finsel.com/public/VS2005/GenerateSVNFilesForSQL2005.

Solution 4

We use Subversion and all we do is save the sql code in the directory for our subversion project and then commit the code to the repository when we are ready and update from the repository before we start working on something already in there.

The real trick is to convince developers to do that. Our dbas do that by deleting any stored proc (or other database object) that isn't in Subversion periodically. Lose stuff once and pretty much no one does it again.

Solution 5

I don't know of a pre-packaged solution, sorry...

... but couldn't you just a little script that connected to the database and saved all the stored procedures to disk as text files? Then the script would add all the text files to the SVN repository by making a system call to 'svn add'.

Then you'd probably want another script to connect to the DB, drop all stored procedures and load all the repository stored procedures from disk. This script would need to be run each time you ran "svn up" and had new/changed stored procedures.

I'm not sure if this can be accomplished with MS SQL, but I'm fairly confident that MySQL would accommodate this. If writing SVN extensions to do this is too complicated, Capistrano supports checkin/checkout scripts, IIRC.

View more solutions

Comments

[Kieran Benton]

Hi Josef, I've registered and tried to download your tool as it looks great but I get the error "Could not find file 'C:\DotNetNuke\Portals\0\Repository\InstallSVNFilesForSQL200‌​5.3a21c4ac-399a-4006‌​-9057-d9f409e13ce3.z‌​ip'." from your site? Is there any chance you will release the source for this?

[Josef]

Soon as I get my site back up, I'll post the code at my public SVN.

[Steve]

If you use ssms to extract your db objects to source files, beware what encoding is used. It's possible that unicode may be used without you knowing it - it least that's what I've experienced. It can be annoying when you want to make a quick change via a text editor and you get gibberish.

[David Atkinson]

I'm the product manager for SQL Source Control, which is available to try in early access. It works with SVN and integrates with SSMS. Sign up at red-gate.com/Products/SQL_Source_Control/index.htm . Comments welcome!

[CMircea]

@Steve, your editor is garbage if it can't handle Unicode.

[David Atkinson]

SQL Source Control 1.0 red-gate.com/products/SQL_Source_Control/index.htm has now been shipped and is available to evaluate/purchase.

[Jeffrey L Whitledge]

@Steve - I can't imagine why you would ever want to use anything other than Unicode nowadays. This is November 2009, not 1989!

[adolf garlic]

Gets interesting when you have differently named linked servers across dev, test, ...

[overloading]

@adolf - which is a great reason not to do that. :-) In situations where I can't control the unfortunate architectural decisions made before me - I try to make my SQL "build scripts" with "if exists" blocks based on the environment (dev,test, etc.) and/or using variables with dynamically built SQL to handle changing DB, Link or Table names between environments. The goal being that the same SQL gets executed on all environments with minimal differences.

[adolf garlic]

I have used a similar technique in the past where the scripts have tokens replaced based on the build environment. Not ideal but it works.

[Conrad]

@Josef - I can't access your svn server or get to your code - is it still active? Can I get the code somehow?

[xr280xr]

@Steve, but thank you making sure we're aware of that. I don't understand why everyone here has to be so rude all the time.

[drizin]

Another alternative is this free application: servantt.com/?so

[drizin]

Your DBAs will love this free application, which does exactly what they are doing manually: servantt.com/?so

[drizin]

A free alternative to RedGate is this free application: servantt.com/?so It's very simple to use, but does the job very well.

[sky91]

Yes, currently doing the same way. But I'm looking for something automatically integrates well with the changes in database schema, view and stored procedure. I think code first Entity Framework will be better in maintenance for the whole project(code + db).