Derik Whittaker

They are not. We've been storing our sql's in source control for years now. Works like a charm! :)

I have never worked in a shop that didn't have a SQL branch in source control.  The only time I DON'T check in SQL is when it's a quick one-off data script to correct a specific inconsistency or other data issue.

I'm in the same boat as some of your other commenters - we keep our sql scripts in source control.  However, to be most effective with this, your dba's must make the shift from managing db objects directly in Enterprise Manager (or what ever db management tool they use) to scripting all the objects and managing them from source control.  

Totally agree.

Put simply, any code artifact that is used to initiate a build, deploy a build, implement application logic should be a configuration control item.

All kinds of build/software configuration issues follow if this is not the case. Issues that are impossible to investigate and resolve, if you can't state definitively what version of which artifact is used.

Mathew Butler

Visual Studio 2003 had "database projects" which helpfully scripted out everything into a project that you could then check-in including a complete build cmd (individual tables/stored procs etc. each got their own file).

This has been deprecated somewhat since then...

[)amien

As Damien pointed there is a "Database Project" in VS 2003 and also in VS 2005 (hidden in "Other project types"). In this project I have all my sql scripts.

Ankh (svn plugin for VS) have some problems with this type of project but there is still Tortoise SVN :-)

Keeping your sql scripts in version control  is a must when working with different versions/releases/branches of a product. You're just asking for trouble trying to do it otherwise. (As you found out).

Stored procedures belong to source control as any other part of code. Really the same ways as C# code does. It's no questin easy decision.

With table structure there is one more thing to remember.

There is not only the code to create the table, but also a code to make a change and transfer data from previous version.  You need to recognize and version all three of them.

Hope somewhere next year we will have automatic system to apply these triplets to production sites. (We target to have hundrests production servers). Hope we can fing something fitting for us. Otherwise we have to develop it.

why dont u try database projects VS2003 and VS 2005

The new "Data Dude" (branded Visual Studio Database Professional, I think) brings database development a long ways forward and makes it a natural step to place in TFS.  All schema objects are represented by scripts (at the most granular level, meaning that PK's are in a separate script from the actual table, etc).  I've played with it a bit and it's not extremely mature, but it's a good first step to bringing DB development in line with the other development tasks done on a project.

I store the definition of my SPs, tables, views and triggers on a Subversion repository, along with my code.  

I wrote <a href="www.gljakal.com/.../index.php">a small program</a> that exports them for me, so it's just a matter of pushing a button before I check in the code :)

Derik.

There is absolutely no sane reason on the planet as to why you should not be storing all SQL change & development scripts in a source control system. I even put additions to my type tables under source control. In fact many professional environments will mandate that you do this.