Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
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.