Posted by Erland Sommarskog on 06/28/05 19:19

Chad Richardson (chad@NIXSPAM_chadrichardson.com) writes:
> Thanks for the explanation. I do have experience with source control tools
> such as VSS and PVCS, but all have been for file/directory based source,
> like VB. How do DB developers apply these principles (check in, check out,
> etc.) to SQL Server? This is something I've curious about for a while now.

They use - or at least should use - files. I've seen a whole lot of
questions on version control of SQL objects as this should be something
difficult or special. It isn't. Source code is source code, and should be
handled as such.

I guess people are tricked by tools that permit you to store things in the
database directly, point-and-click GUI:n for creating tables etc. But all
of that is really files.

The one gotcha there is if you use a tool like Query Analyzer for editing
your SQL objects, is that you disrupt the normal procedure which is
1) check out 2) edit 3) save 4) compile 5) test 6) back to 2 until it
works 7) check in. With a tool like QA, 3 is taken out of the chain, which
can lead to that what you check is not what you tested.

In our shop, we avoid this problem by using a third-party editor, Textpad.
It has no special features for SQL - but it is a better editor than QA.
From Textpad 3 and 4 is one key-click, as we can activate a command-line
from Textpad. We have our own load tool for quite a few bells and whistles,
but the tool could be command-line OSQL.

The thing people seem to want to do, is to take the SQL objects from
the database, but this is actually really wrong when you think of it.
If you work in VB, would get the input for the version-control system
by disassembling the object modules?


--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinfo/productdoc/2000/books.asp

[Back to original message]