Results 1 to 6 of 6
  1. #1
    Join Date
    Nov 2002
    Posts
    12

    Question Unanswered: How to programmatically clone a database?

    Howdy,

    Is the any easy way to clone a database programatically?
    I've searched the web but did not come up with anything.

    At the moment I create a new blank database (based on the model database)
    and create tables, indexes, etc. via asp. (The databases are always exactly
    the same)

    It seems to me that it would be a better option to
    create one database with tables, indexes, etc and copy
    it to a new database (on the same server).

    One of the options I'm considering would be to create a database,
    fill it with tables and indexes, etc. and then detach it.
    Whenever I need a new database all I would have to do is use the
    file system object to copy and rename the mdf file and then reattach the
    new mdf file.

    I realise that I could also make the changes to the model
    database so that all new databases have the same structure
    but that would be my last resort.

    Is there any easier way to do this? A stored procedure perhaps?

    You're opinions and advice would be welcomed.

  2. #2
    Join Date
    Nov 2004
    Location
    on the wrong server
    Posts
    8,835
    Provided Answers: 6
    In the EM right click on your database and go to all tasks\generate sql scripts and have the EM script out the whole database. modify the code as needed and wrap it into a stored procedure.

    but you're going to have to account for making the database names different.

    multiple databases with the same structure is generally a bad idea and a couple of the regulars in this forum are probably gearing up their tongue thrashings for you.
    “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.

  3. #3
    Join Date
    Nov 2002
    Posts
    12
    Thanks for your reply.

    multiple databases with the same structure is generally a bad idea
    Pardon my ignorance but why?

  4. #4
    Join Date
    Nov 2004
    Location
    on the wrong server
    Posts
    8,835
    Provided Answers: 6
    it all depends on your rationale but...

    it is more to maintain (backups, reindexing etc...)

    just like repetitive application code, if you make a change, you need to make a change to all of the databases and what if you miss something? Major make-work headache.

    it could complicate report writing if you need to report across databases. you added three databases this week, do you need to add these databases to your report code.

    And there are more reasons and not enough time.

    in the long term it is a lot less work to build your rationale for dividing your data into your database structure and to just have one database and there are different ways to do this depending on your situation.
    “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.

  5. #5
    Join Date
    Nov 2002
    Posts
    12
    I suppose it depends on the environment. Its actually a lot less work for me with multiple databases. Its a hosted environment with a database for each customer.

    If they leave, I just drop the db, rather than wading through one massive database deleting data specific to only them. Also they each require their own logins and sometimes off site backups. There are a few more reasons but I won't go into them.

    Thanks for your suggestion, I'll give it a try later today.

  6. #6
    Join Date
    Apr 2003
    Location
    Phoenix, AZ
    Posts
    177
    Podge, we actually maintain a "virgin" database with the current structure and certain tables loaded (ie, reference tables). To clone we just have a t-sql script that does a backup (it's small) and then creates the new database after we edit parameters like database name, files names and location, and minimum sizes.

    And by the way, we run 50 copies of the same database structure on one server.
    Fred Prose

Posting Permissions

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