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.
views:
6764answers:
14
A:
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.
Oli
2008-09-28 19:35:02
+18
A:
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.
Ron
Ron Savage
2008-09-28 19:36:15
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.
Steve
2009-11-23 17:07:43
@Steve, your editor is garbage if it can't handle Unicode.
iconiK
2010-04-13 03:47:55
@Steve - I can't imagine why you would ever want to use anything other than Unicode nowadays. This is November 2009, not 1989!
Jeffrey L Whitledge
2010-06-30 14:12:42
Gets interesting when you have differently named linked servers across dev, test, ...
adolf garlic
2010-08-04 13:25:49
@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.
Ron Savage
2010-08-04 21:28:01
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.
adolf garlic
2010-08-05 16:21:45
+7
A:
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
Thomas Wagner
2008-09-28 19:38:48
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 http://www.red-gate.com/Products/SQL_Source_Control/index.htm . Comments welcome!
David Atkinson
2010-02-22 23:43:23
SQL Source Control 1.0 http://www.red-gate.com/products/SQL_Source_Control/index.htm has now been shipped and is available to evaluate/purchase.
David Atkinson
2010-06-30 12:17:28
+1
A:
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.
ceretullis
2008-09-28 19:42:08
+2
A:
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.
HLGEM
2008-09-28 20:58:33
+4
A:
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.
Josef
2008-09-29 12:39:44
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\InstallSVNFilesForSQL2005.3a21c4ac-399a-4006-9057-d9f409e13ce3.zip'." from your site? Is there any chance you will release the source for this?
Kieran Benton
2009-03-07 12:33:09
+1
A:
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.
Unsliced
2008-09-29 12:44:12
$499 seems a little steep... also here is the text of the link: http://www.nobhillsoft.com/Randolph.aspx
Brian Vander Plaats
2010-05-19 00:56:49
A:
Here is a complete solution: http://blog.boxedbits.com/archives/133 It uses a combination of vbs script and SQL. Works fine for me!
Tom
2009-11-23 16:49:10
A:
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.
Brian Vander Plaats
2010-05-19 01:22:04
A:
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
Andreas Rehm
2010-06-30 13:50:58
A:
I strongly disagree with using subversion to source control stored procedures.
What if you had to include DROP and ADD details to every C# file you were working with, in order to "update" the file system it lived in? Ridiculous, right? You don't care how the file is saved, and you certainly don't want the details of how that happens intruding in your code.
And yet, when you use standard source control to version stored procedures, you get into the rank silliness of having to include DROP PROCEDURE and ADD PROCEDURE and GO statements in every godforsaken "file". Irrelevant, cookie-cutter code repeated on such a scale is a strong indicator that something isn't being done right.
Stored procedures are not "files", they are data. And data belongs in a database.
PJ6
2010-08-10 15:20:08
While I do agree that including `DROP` and/or `ALTER` statements is superfluous, I don't agree on SPs (or anything but table contents) being data. All object definitions (typically expressed as `CREATE` script) really are source code and belong into source control. The right tools can then compare the effective DB schema with the one defined in the scripts, and make at least non-destructive changes (e.g. add/remove/update all SPs, views, functions, triggers) and tell you what needs to be taken care of with an update script for modifying the tables without losing data.
Lucero
2010-10-03 08:30:38
A:
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
Eduardo
2010-08-10 15:29:37