Managing Create Scripts in Visual Studio .NET

When Create scripts are locked, you can open them for viewing in the editor, but Visual Studio .NET will prevent you from changing them until you check them out.

To view a Create script, right-click the script you want to review and select Open. Visual Studio .NET opens a copy of the Create script but marks it "read-only."

The following steps demonstrate how to change a stored procedure:

1. Close the window with the read-only version of the Create script.

2. Right-click the script for a stored procedure and select Check Out from the pop-up menu. The program prompts you for comment:

   

3. Make some trivial change to the stored procedure.

4. Save the changes (File | Save) in the change file.

5. Right-click the file and choose Check In from the menu. The program prompts you for comment again.

   Tip 

   Take the time to describe what changes you made in your comment. This will he incredibly helpful if some detective work is required later.

6. Click Check In. Visual Studio .NET saves the changes in Visual SourceSafe and locks the Create script.

7. Keep in mind that at this point, the stored procedure does not yet exist in SQL Server! You must right-click the file and select Run to deploy it to the default database. Visual Studio .NET opens the Database Output pane to show the results (and possibly errors) of the execution; however, it probably makes more sense to deploy the change to the development SQL Server before it is saved to the VSS database.

   Note 

   Unfortunately, this solution does not prevent another developer from using some other tool to change a database object directly in the database. You can even open Server Explorer in Visual Studio .NET to change one without source code control. Visual SourceSafe works only through consensus; loose cannons can still wreak havoc on your development ship.

   To promote the change to another server, you can choose the Run On option in the context menu of the Change script.

   Tip 

   When I first started to use Visual SourceSafe, the directions implied by the terms "Check Out" and "Check In" sounded inverted to me. Just think of Visual SourceSafe as an actual safe from which you are taking your code and into which you subsequently put back your code after you are done with it.

8. Now, go back and check out the same stored procedure again.

9. Open it and reverse your previous changes.

10. Save the stored procedure.

11. Run the Change script against the server to test it (right-click the Change script and select Run).

Assume that you are not satisfied with these changes and that you want to abandon them, (i.e., that you have tested them and the result is not what you expected.) To reverse changes,

1. Select Undo Check Out from the context menu. The Visual SourceSafe Server locks the file again and uses the previous copy from Visual SourceSafe to reverse the changes in the local file.

2. To reverse changes to the database, you must run the Change script again.

Note 

Undo Check Out does not actually change any code already deployed hut merely reverses the check out process.