Synchronize two SQL Server databases

You are furiously pounding code on your computer and in the meantime making small changes to the local (development) version of the database as the need arises – add a column, change the type and width of another, add a view, make a change to a stored procedure and so on. At some point in the early morning hours as the World wakes up you are ready to publish your work on the production server, somewhere… – just a few clicks and the early risers will see your masterpiece (application) in action. Well, not so fast unfortunately, all those changes you made to the development database must be made to the production database otherwise your application is not going to work, is it? Now, that is some painful and tedious work to say the least. What if you forget something? And here is a twist to make this a real nightmarish scenario – remember last week when the client needed those urgent changes and you were forced to do the “unthinkable” – make changes right on the production database! Worst yet, you realize that you never got around to bringing those changes down to your local, development database – no words can describe the pain you must feel at that moment!

Is this time for panic? No it is not, it is time for xSQL Object – in just a few clicks it will show you exactly where the differences are on both sides and better yet auto-generate the scripts that you need to quickly and safely make the changes.

Download it now and eliminate “the pain” – free lite edition with no strings attached. Supports SQL Server 2000, SQL Server 2005 and SQL Server 2008.

Deploying database schema changes to hundreds of clients

This post is directed to software publishers who have published software that uses SQL Server on the back end. Here is a simple scenario you run into: you release the software and within a couple of months you have successfully deployed it to tenths of customers. In the meantime you have discovered a flaw on a stored procedure which needs to be changed, you want to add a couple of reports for which you need to add a couple of new supporting views, a column on a table needs to be changed from varchar(50) to varchar(100) etc. – you get the picture. The question is: how do you make those changes on all those customers’ sites? You could send them a change script that will alter and add those objects in the database but a lot of the customers don’t know anything about SQL Server and don’t won’t to deal with those scripts. Furthermore, if this is not the first iteration of changes and the customers are using different versions of your database the script you send must be customized for each version. The main point here is that sending the customers a t-sql change script and asking them to apply it is generally not going to work.

So, what do you do? Well, you use xSQL Builder which was designed to alleviate this kind of trouble. xSQL Builder is extremely easy to use but at the same time, if your scenario is more complicated it gives you all the flexibility to customize it to best fit your needs. How does it work? You go through a simple wizard that takes no more than a couple of minutes and allows you to choose the source or “master” database which you want to deploy to your customers, set a few parameters and generate an executable package that you can then send to your clients. The client runs the executable which compares the embedded schema of the source/master database with the client’s version of the database, generates a synchronization script, executes the script and emails you the results. Now, you have to admit that is a cool and extremely efficient way to deploy your database schema changes.

You can download your copy of xSQL Builder from: http://www.xsql.com/download/sql_database_deployment_builder/