views:

306

answers:

4

I'm trying to implement database source control.

the tool I need should create a separate file for each object in the database, preferably arranged in folders, like

stored procedures functions views tables

and it would be great being able to also dump the results of certain queries, in order to keep track of the data changes in several configuration tables...

I wonder if there's is already a tool that can handle this kind of stuff...

--

just to clear a few things...

I'm already using sql delta to handle the update scripts...

I'd like to have scripts of the DB in order to use with subversion, so I can trace what objects where changed with each commit, without having to study the update scripts...

I'm developing a nice vb script with SQL Distributed Management Objects (SQL-DMO), I'll tell how it goes...

What's good about having my own solution, is that I can also include the outputs of queries or stored procedure execution, to trace the changes in certain tables, server configuration, the growth of the database, well, whatever I can dump to a text file...

A: 

You may try Wizardby, which is not precisely what you're asking for, but still can help you handling database change management. It can reverse-engineer your database schema (well, a subset of it) and then write so-called "migrations" in a special platform-independent DSL:

version 20090331140131:
    oxite_FileResource:
        FileResourceID type => PK, primary-key => true
        SiteID type => Guid, nullable => false
        FileResourceName type => LongName
        CreatorUserID references => oxite_User
        Data type => Binary
        ContentType type => AnsiString, length => 25, nullable => false
        Path type => String, length => 1000, nullable => false
        State type => Byte, nullable => false
        CreatedDate type => DateTime, nullable => false
        ModifiedDate type => DateTime, nullable => false 

    oxite_UserFileResourceRelationship:
        UserID references => oxite_User
        FileResourceID references => oxite_FileResource:
            add index unique => true

        index "" columns => [UserID, FileResourceID], unique => true, clustered => true
Anton Gogolev
+2  A: 

If I understand you correctly, you need two things: first you need to generate the scripts from database metadata (tables, views, stored procs, etc), and once this is done, you need to use some kind of consistent methodology for script versioning.

If you already have your metadat and data in the database, I don't see what would prevent you from using SQL Management Studio (or SQL Enterprise Manager) to generate scripts from database objects: see How to: Generate a Script (SQL Server Management Studio). This should work for SQL Server 2000, 2005, etc. Keep in mind that you can customize script generation settings, e.g. instead of one huge script, you can use individual scripts for each object. You may need to write some scripts to populate tables with data (I'm not sure if the wizard supports data extraction).

Once you got the scripts, you will probably have to manually distribute them between specific folders and when this is done, you should be ready to check them in source control. From this point on you need to figure out the methodology for the subsequent database installations, upgrades, and repairs. This is a rather complex task, covering which would take longer than a simple answer. If you are interested in possible options, check my Database installer revised post which mentions a number approaches and references several articles addressing database versioning (sorry for self-promotion, but I do not want to repeat the same info).

Alek Davis
+1  A: 

Most of the tools in this field are not free but there's an open source project, ScriptDB, which may meet your needs for generating scripts.

This won't solve the problem of how to apply the scripts to the database in the right order - if you don't want to pay, you may have to improvise your own.

Ed Harper
+2  A: 

I use ScriptDB for exactly this purpose. The only thing I had to change was to remove the date of scripting in the generated files. Otherwise files are always marked as changed in Subversion.

Here is the batch I use. svnclient is the tool from codeplex svncompletesync.codeplex.com, to check in all files from a folder into subversion.:

svn checkout "http://svn/myproject" D:\Projekte\db_svn\myproject

ScriptDB "D:\temp\scriptdb" myserver mydb mylogin mypwd

del "D:\Projekte\db_svn\myproject\Schema Objects\*.sql" /q /s

xcopy "D:\temp\scriptdb\myserver\mydb\Schema Objects\*.sql" "D:\Projekte\db_svn\myproject\Schema Objects" /e /y /i

svnclient "D:\Projekte\db_svn\myproject" -m "commit durch svncompletesync"

Malcolm Frexner
When I run ScriptDB, the created files do not contain the date of scripting. But I have another big problem (I'm trying to use ScriptDB with Subversion as well):when I delete an object in my database and run ScriptDB again, it does not delete the already generated script file for this object. How did you solve this? I tried to delete the created files before running ScriptDB again, but then the next commit fails because the .svn folders are gone as well...
haarrrgh
*smashed forehead against keyboard* Sometimes you don't see the obvious: del c:\folder\*.sql only deletes the sql files and leaves the .svn folders intact. That's exactly what I was looking for (and didn't see). Thank you!
haarrrgh