Patch an MS-SQL-Server database in live environment

Question

I have an application that uses an MS-SQL-Server to store it's data. We will roll out the application in several steps, so users can test first basic functionalities and we add functions over time.

Probably, this will cause changes to the database. In early stages, we can just drop the whole database and create everything anew with a script. But eventually, users want to keep their test data. For example, if I add a new column to a table, I don't want to delete and create anew the whole table, loosing all the data the user has stored so far in the process.

So, what I need is a script, that updates myDatabase v1.0 to myDatabase v2.0.

My question is: What is the best way to create such an update script? Do I have to manually keep track of all the changes and then assemble the update script myself? Or is there a function which could (semi)automatically create the update script from the old and the new database?

And finally, what is the best way to apply this patch? I have a ASP.NET Web-API so, I could create a controller api/updates/v1.0-to-v2.0 How would the code for applying the script at the server would look like?

Thanks in advance,
Frank

Answer 1

I'm working on a solution to this very problem, check out dbpatcher.com the software that I've created will help to make migrating database changes easier. I'm putting together the website at the moment so would welcome feedback. The program itself isn't yet available, as I'm trying to figure out the details for publishing.

Answer 2

If this is an on-going concern (corporate), you should really consider different environments, ie. test, staging and production. This way you can test your deployments and database scripting changes in a pristine environment (something that looks exactly like production).

Given that, to answer your question, there really isn't a good way to do this. I've seen people use diff tools to detect the differences between schema's, and it creates scripts to sync two schema's, but it's not fool proof.

I find that scripting the changes and combining that with version control and an installation procedure (manual or automated) is the only way to get consistent results, and even that fails sometimes.

Code first entity framework is attempting to solve that issue, but it's not an option for a number of shops.

I would love to see a good tool to manage this, but the set of diverse frameworks and human error are the biggest problems here.

In terms of down time, there really is no such thing as live in-place upgrades of web applications. There are ways to mitigate it to a minimum, like update one set of a load balanced Web/App server at a time and then fail users to the new software. If your doing table alterations, the likelyhood that your not going to lock the table and interrupt your users are pretty low.

Answer 3

Thanks for your replies!

I have different environments, my concern is how to change the database schema without loosing data in the production environment (if possible, of course). Downtime is not so much a problem. As I am not productive yet, I simply create a script to recreate the whole database, but when the user has live data stored, he would probably be a bit ... upset.

There is a nice tool from redgate , that seems to solve that problem, but I did not checked it yet.