Results 1 to 4 of 4
  1. #1
    Join Date
    Feb 2006

    Unanswered: Moving DB changes from one server to another

    I'm currently working on a project, with development at my location and production at another. My question is what is the best way to copy database changes, ie adding/removing fields, without having to copy over the existing data. I have been just noting what fields I add and remove, and going to the production server and doing it by hand, but this obviously isnt the fastest way to do it. Essentially when I add a new module to the system on production, I have to manipulate existing database tables. I want to copy the schema of those tables to production, but I dont want to lose any existing data on production. Thanks in advance.

  2. #2
    Join Date
    May 2004
    Columbus, OH

    It probably seems old fashioned as heck, but the developers that I work with created a TSQL script that they keep adding their changes to.

    Now, these changes go back about 2-3 years so if someone forgets to run the script they can always run the most recent script and get the changes that they need.

    The script is maintained in a revision control system so only one person can make changes at a time and in the event of a significant error they can go back to a trusted version.

    Life....Just another opportunity to live another day like a pirate....

  3. #3
    Join Date
    Aug 2004
    Calgary, Alberta
    If you're really lazy like I am, you can script the changes in enterprise manager, save the sql and run that on your other box.

    Or like HubarttMeister said, you could keep a master script. I would generate this master script using "generate sql" in enterprise manager, and then keep updating it in a source control.

    Usually, in a source control you should be able to diff older files easily, and see what changes have been made.

    There is nothing more helpless and irresponsible than a man in the depths of an ether binge. -HST

  4. #4
    Join Date
    Nov 2004
    on the wrong server
    Provided Answers: 6
    this is what i do for version control. I keep all of my sps, views, triggers and functions in seperate sql files in Vault (like sourcesafe) with IF EXISTS DROP object GO CREATE object statements. I keep all table structure changes in one sql file for each version. when it is time for an upgrade I drop all of these files in a directory. I wrote a little utility that searches these directories and writes an osql batch file for all of the .sql object files. The table structure file gets executed first and then all of the object changes. The osql executions logs the results to a text file that then gets reviewed for errors.
    “If one brings so much courage to this world the world has to kill them or break them, so of course it kills them. The world breaks every one and afterward many are strong at the broken places. But those that will not break it kills. It kills the very good and the very gentle and the very brave impartially. If you are none of these you can be sure it will kill you too but there will be no special hurry.” Earnest Hemingway, A Farewell To Arms.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts