Any .NET developer who has worked with SQL Server has at some point had to deal with the challenge of transferring database changes from the development db to testing or production db. It's always the same, you start your "application enhancement" project with a clear vision of the outcome, you potentially identify the database objects, tables, views, stored procedures, functions etc. that you may have to tweak, completely revamp or build from scratch.
As you move along new changes and additions to the database structure (aka schema) become necessary - you keep making those changes to the database and depending on your type (from highly organized to totally messy), experience (from decades of experience to a rookie programmer) etc. how you handle those changes may vary from the "meticulously document everything" approach to the "I will remember those changes I am making" approach.
While the "document everything" approach is commendable it does unfortunately come with a hefty price tag - a lot of extra hours will be spent on that documentation and to make matters worse no intelligent programmer who gets the adrenaline rush from coming up with ingenious approaches to handling technical challenges enjoys dealing with it.
On the other hand, the "I will remember" approach is not only non-commendable but depending on the complexity and sensitivity of the project it may at times be disastrous - otherwise genius programmers pulling their hair trying to figure out why the application is working fine on their development environment but is going haywire on the production, operations people going nuts over the malfunctioning of the system on which their livelihood depends etc.
So what is an intelligent .NET programmer to do?
Fortunately, there is no need to choose between bad and worst - there is no need to spend all those hours documenting everything (don't take this the wrong way - any good programmer will always take the time to provide sufficient documentation to allow a comparably intelligent human to understand why something was done, who did it and when) nor there is a need to remember what changes you are making. xSQL Object, allows the user to compare two databases and clearly identify all the changes that have been made on the structure (aka schema) of one database versus the other. But wait, it goes way further than that - it allows the
user to generate a safe change script that will apply (transfer) all those changes to the destination database in a single click. Now that's efficiency - something you would have to take hours to do you can handle with xSQL Object in minutes and not only that you can proudly archive the detailed "documentation" of all the changes you made to the database - not only is that commendable but it feels great too - you are doing an outstanding job without having to waste a minute on it.
Here is where things get even better - xSQL Object is completely free, no strings attached, for SQL Server Express edition. And what if I am not using SQL Express but some other edition of SQL Server like the Workgroup Edition, Standard Edition, Enterprise Edition etc? Not to worry, we have thought of that too - xSQL Object is free for those other editions too as long as the number of the objects in your databases is under certain limits.