Here is a common scenario I run into:
A while back you have developed a web site that uses SQL Server on the back-end. The initial deployment was a breeze and everything worked perfectly. Now it is time to tweak and enhance the website with new features and functionality. In addition of making changes and additions in your code you start making changes to the database as well:
- added a couple of new tables
- modified a handful of tables (added columns, changed column types, added indexes, added /changed constraints, added new relationships etc.)
- added a few new stored procedures and views and modified some more of them
- added / modified a dozen user defined functions
- added / modified triggers
- etc., etc…
And all the while you diligently kept track of every change you were making knowing that you would soon need that log of changes.
After two months of hard work and sleepless nights, after testing and retesting everything you are ready to deploy your new version of the website – you know that deploying the application is a click of a button but the application is not going to work unless all the database changes you made are correctly propagated to the production database. You look at your long list of changes and realize that it is going to take hours to manually apply those changes. You wish you could just back up your development database and restore it on the production server but the production database contains live data which must be preserved.
So, you tell your client that you need to take the website off-line from 10 PM on Saturday night to 6 AM on Sunday morning. And when that day comes you take the site off-line, make a full backup of the database and start applying those changes one after the other. The cascading “can’t change this 'object' because it references this other 'object'” messages start to drive you insane but you have to do this so you keep moving along. After hours of frustration you seem to have reached the end of your list and as the sun is dawning you start getting more cheerful. You click on that “button” and publish your application – you run through some tests and everything seems to be working great!
You write an email to all people involved to let them know that you successfully published the new version of the website – pet yourself on the back and go to take a few hours of much deserved sleep. You have just fallen asleep when the phone rings and you get up again to take your client’s frantic call - customers are getting errors and not being able to complete their transactions – something is very wrong! Your nightmare scenario has come true! You jump into action again, quickly look at the error logs and try to determine if the cause is something you can fix quickly or whether you need to restore the old version of the database and application. Fortunately for you this time you discover that the culprit is a single Stored Procedure that had been modified but which somehow you missed. You change that SP and everything is fine – you are finally relieved, it could have been a lot worst!
The question is why anyone would go through this pain when they can use a tool like xSQL Object which in matter of minutes can identify all the database changes that were made and generate a safe SQL change script that will propagate those changes to the production server. It appears to be even more puzzling when considering that xSQL Object is completely free for SQL Server Express and it is also free for other editions of SQL Server as long as the database contains less than a certain number of objects. Even if you were in the small group of users (less than 10% of our user base) who work with larger databases and have to pay a couple hundred dollars xSQL Object more than pays for itself in just one time you use it. The answer unfortunately lies in our inability to reach out to all those potential users to let them know what they are missing. So, if you read through this please help spread the word – let all your friends and colleagues know that they can download this tool and use it to save many valuable hours of their time.
No comments:
Post a Comment