Any software developer who has worked with SQL Server (or any database for that matter) has at some point had to deal with the challenge of propagating the database changes from the development database to the QA/staging database, to the production database. The process is 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, triggers, functions etc. that you may have to tweak, completely revamp, or write from scratch.
As you move along new changes and additions to the database structure (aka database 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 documentation.
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 on their development environment but is going haywire on the production, operations people going nuts over the malfunctioning of the system, etc.
So what is an intelligent software 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 wrong, 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 is there a need to remember what changes you are making. xSQL Software's SQL Schema Compare, 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 that would otherwise take hours to do you can handle with SQL Schema Compare in minutes, and you can easily 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.