How do I manage changes in SQL Server objects?

In one man operations, it's not that big of a deal. You find a bug in a stored procedure, you fix it, and deploy it. In larger shops, however, it's just not that easy. Change management becomes a very important issue when multiple developers may have to work on the same procedures, functions, triggers, and other database objects. 
 
SQL Server does not have built-in version control, however you can use Visual Studio.NET's Visual SourceSafe integration, alongside the server explorer, to check objects in and out of SourceSafe. This is hardly a complete solution, and has a few problems. For example, it is not trivial to get set up; the changes are checked in from the account that SQL Server runs as, as opposed to the user who actually made the changes; and finally, if your scripts are larger than 4 KB, you might need a workaround (see KB #313993). 
 
Not that you have to use Visual Studio.NET's SourceSafe integration functionality, nor is Visual SourceSafe your only option. There are plenty of third party products that will help you manage changing software; however, successful source code control is more about following a process than about which software package you choose. All it takes is one lazy developer to undo all of the good that a $10,000 source control system brings to the table. 
 
    abCVS 
 
    Cast Software 
 
    CVS 
 
    Merant ECM 
 
    Merant Version Manager 
 
    Embarcadero Change Manager 
 
    Embarcadero RapidSQL 
 
    mssqlXpress 
 
    Perforce 
 
    Rational ClearCase 
 
    SourceGear Vault 
 
    Surround SCM 
 
In addition, the following products integrate with Visual SourceSafe to make database management easier. 
 
    AbaPerls 
 
    DBGhost 
 
    SQL Source Control 
 
All that being said, here is how we do it in our shop. We use Visual SourceSafe. SQL Server objects are scripted, saved to disk, and checked in. (We have separate sub-projects for each type of object, such as tables, views, stored procedures, functions, triggers, etc.) When an object needs to be modified, it is checked out, modified, applied to a test server, verified, then scripted out and checked back in. Deployment is usally handled separately, unless it is a critical issue that needs an immediate fix. The developer who modified the code is, ideally, not responsible for deployment to the live system(s), to ensure that at least two sets of eyes have verified the changes. And of course, it is all documented in an issue tracking system.