Home/ Questions/Q 3333016
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-17T23:45:00+00:00

In our project we have several production databases and many devs. Each production database

  • 0

In our project we have several production databases and many devs. Each production database represents some “sub-project/localization version”. We use SQL Server 2008.

So, I need to develop database versioning strategy using MS Visual Studio Database Project.
I have read a lot of articles about database versioning and database projects, but I still have a lot of questions:

  1. How developers should implement
    theirs changes to db project? (Best practice)

  2. How to generate the 100% workable
    “latest version” deploy script
    without human intervention (skipping
    some objects, rewriting some changes,
    etc)?

  3. How to manage data changes with MS
    Visual Studio Database Project? I
    know about pre-/post-deploy scripts,
    but I think it cant resolve this
    problem. (Example: I need to remap
    some table into another).

The “ideal solution” would be:

  1. Developers generates and maintains Database Project for database [ProductionDB].

  2. With new release I deploy Database Project to the [ProductionDB] with all necessary
    changes.

  3. Developers changes Database Project and writes some data manipulation scripts for concrete changes.

  4. With new release I deploy Database Project to the [ProductionDB] with all necessary changes.

So, The final question: Is it posible to use Database Project for the purposes described above or somebody uses similar scenario/solution?

PS: I have already read following discussions:

  1. Database changes versioning [closed]
  2. How do I version my MS SQL database in SVN?
  3. Looking for solution for database versioning
  4. Is there a version control system for database structure changes?
Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Database project is precisely used for most of the reasons that you have mentioned here –

    1. Developers just checkout the database script files, make the changes, and check them back in. Mind you they will be changing .sql files and not directly the objects present in any dev database. So if you need to add two columns to a database table, you will modify the create table script for this table, and NOT write an alter script for this table.

    2. If you have the target old version DB schema – you can just deploy this project with the latest files to that database and a deployment script will get created (with the necessary alter statements). There is a project setting that allows you to opt whether the deployment script should also be run against the db when you ‘deploy’.

    3. The deployment script can be a deliverable that is separately tested against a prod copy and then applied to prod as a patch.

    About data manipulation scripts I am not very sure, however for all other purposes that you mentioned, a database project is perfect.

    • 0