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

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.

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.

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

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.

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.

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.

Best way - one which works for you.

Easiest way - one that doesn't currently exist.

We use a semi-manual method (scripts under source control, small subset of people able to deploy stored procedures to the production server, changes to the schema should be reflected in changes to the underlying checked in files).

What we should do is implement some sort of source control vs plaintext schema dump diff ... but it generally 'works for us' although it's a really faff most of the time.

I agree that if possible, you should use database projects to version your db along with your application source.

However, if you are in an enterprise scenario, you should also consider using a tool to track changes on the server, and version those changes. Just because the database project exists doesn't mean some admin or developer can't change those sprocs on the server.

We do dumps to plaintext and keep them in our VCS.

You'd be able to script a backup-and-commit to do something similar.

I'm using scriptdb.exe from http://scriptdb.codeplex.com/

And it might be usefull to use the rails way: http://code.google.com/p/migratordotnet/wiki/GettingStarted

Use versaplex for dumping your schema: http://code.google.com/p/versaplex/

Versaplex comes with Schemamatic, which reads database schema (tables, SPs, etc) and also data (data is dumped as CSV). I use it, with SVN and git, and it's awesome :) If you need help let me know, it's worth a try! http://github.com/eduardok/versaplex