[cvsnt] Managing SQL Server source with CVS?

Malathi.Chandrasekaran at cognizant.com Malathi.Chandrasekaran at cognizant.com
Tue Aug 14 09:34:59 BST 2007


Hi Glenn,
 
Can you kindly send me the dump scripts that you have created. It would
be a lot helpful for me. I am not even sure if this is your mail id,
since this post was made couple of years back...
 

[cvsnt] Managing SQL Server source with CVS?

Glen Starrett grstarrett at cox.net
<mailto:cvsnt%40cvsnt.org?Subject=%5Bcvsnt%5D%20Managing%20SQL%20Server%
20source%20with%20CVS%3F&In-Reply-To=bonobk%24t2s%241%40sisko.local.nodo
main.org> 
Mon Nov 10 16:28:10 GMT 2003 

*	Previous message: [cvsnt] Managing SQL Server source with CVS?
<http://www.cvsnt.org/pipermail/cvsnt/2003-November/009245.html> 
*	Next message: [cvsnt] Re: Managing SQL Server source with CVS?
<http://www.cvsnt.org/pipermail/cvsnt/2003-November/009262.html> 
*	Messages sorted by: [ date ]
<http://www.cvsnt.org/pipermail/cvsnt/2003-November/date.html#9258>  [
thread ]
<http://www.cvsnt.org/pipermail/cvsnt/2003-November/thread.html#9258>  [
subject ]
<http://www.cvsnt.org/pipermail/cvsnt/2003-November/subject.html#9258>
[ author ]
<http://www.cvsnt.org/pipermail/cvsnt/2003-November/author.html#9258>  

________________________________

> Does anyone know of any tools available that could ease version
> management of (MS) SQL Server sources? Our apps are for a large part
> written as stored procedures and triggers. Currently the way is to
> initiate an export to files and check those files into CVS.
> We use Enterprise Manager's built-in Generate SQL Script function to
[snip]

What I do is keep all my SQL source in a directory that is under CVS
control.  I have a script to post changed files to SQL (it takes a
manifest
list so that only the desired files are processed).  I also have a
script to
pull the files out of SQL server in the manner of SEM but it's a lot
more
consistent (no click-click-click oops I forgot to set ANSI,
click-click-rename stuff).  Nothing too fancy--no integration with SEM,
but
they work for me.

With my situation I have at 4 instances of my database:  My DEV, other
dev's
DEV (in India), TEST, and PROD.  This allows me to flow changes out and
into
the TEST/PROD very consistently.  

The way I'm using this:

--Initially I pull all SQL objects from my DB (tables, procs, triggers
if
any, etc.)

--All object scripts have full DROP then CREATE syntax so they can be
re-run
(*disadvantage for tables! See later step)

--As I update the database objects, I update my manifest for that
release
(e.g. R120-updates.txt has the list of procs in it)

--For schema changes I put a "table changes" script at the head of that
schema that first looks for the new column or changed element then, if
not
present, executes the change script to update the schema on that table.

Whenever an object is changed, I change it in DEV typically
interactively
since that's a LOT faster to author / debug.  Then I update the object's
file in my file system & CVS with the update manifest and can run my
MakeDB
script against TEST to make sure I didn't miss anything.  NO changes are
made directly in TEST to ensure that I have a good manifest for the
later
PROD update.

I've never tried using my 'dump' script for 2-way updating, but I'd
imagine
it would work fine since that is what creates the initial files anyway
(it's
been a long while since I ran it though, so I don't know what state it's
in
exactly).

I can email you the scripts if you like.  The only thing I'd ask in
return
is if you could document your usage of it to the cvsnt wiki for other's
future reference :)  (optional, but a good karma step).

Glen Starrett
 

 
 
Thanks & Regards,
Malathi Chandrasekaran
 
DACoE - Data Architecture Center of Excellence |
https://dacoe.cognizant.com <https://dacoe.cognizant.com/>  
Email: malathi.chandrasekaran at cognizant.com
<mailto:malathi.chandrasekaran at cognizant.com>   | VNet: 435028 |
Cognizant Technology Solutions
 
 


This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information.
If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. 
Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email or any action taken in reliance on this e-mail is strictly 
prohibited and may be unlawful.


More information about the cvsnt mailing list