Visual SourceSafe is a tool you can use to manage the development of an Access application being worked on by a team of developers. Once a database has been placed under SourceSafe control, each object must be checked out before it's modified. Once the changes to the object have been made, the object is checked in so that other developers can see the changes. At any time, you can get the following information about the objects in the database:
Which objects are checked out
A history of everything that has happened to an object
The differences between two versions of an object
Using Visual SourceSafe, you can easily revert an object to a previous version or merge different versions of an object. Visual SourceSafe is not only a tool for teams of developers, but also for an individual developer who wants to keep every version of each object in an application. It's a phenomenal tool that helps make Access a serious developer environment.
Visual SourceSafe can be used only with the Office Developer Edition of Access; however, it doesn't ship with the Office Developer Edition. It's included as part of the Enterprise edition of Visual Basic, or it can be bought as a standalone product. In fact, Visual SourceSafe isn't the only source-code control product that can be used with the Office Developer Edition. Instead, the Office Developer Edition supplies a software component, the Microsoft Access Source Code Control component, that can integrate various source-code control products into Access. To integrate Visual SourceSafe or another version control product into Access, you need to install both the ODE-supplied control and the client part of your version control product.
You integrate Visual SourceSafe with Access by running Netsetup.exe from the Visual SourceSafe directory. This sets up the Visual SourceSafe client. Until you do this, if you're running the Office Developer Edition of Access, you get an error message each time you launch Access, indicating that Access isn't under any source-code control application. Once you install Visual SourceSafe, you'll see a SourceSafe entry under the Tools menu:
Create Database from SourceSafe Project
Add Database to SourceSafe
Run SourceSafe
Options
The Create Database from SourceSafe Project menu item allows you to create a local database from an existing Visual SourceSafe project. The Add Database to SourceSafe option creates a Visual SourceSafe project from the open database. The Run SourceSafe option runs the Visual SourceSafe Explorer. Finally, the Options menu item lets you configure different Visual SourceSafe options. Each of these menu items is covered in the following sections.
When you want to place a database under SourceSafe control, you create it from a SourceSafe project; this database becomes the master copy. Each developer works on a local copy of the database, and no objects in the database can be modified until they're checked out. When a developer checks out an object, it's copied from Visual SourceSafe into the local database. No other developers see changes made to the object until it's checked back in. When the developer checks the object back in, it's copied from the local database to the Visual SourceSafe project.
With the exception of modules, only one person can check out an object at a time. This means that two people can't make changes to any other types of objects under SourceSafe control simultaneously. Multiple developers, however, can check out modules. When you check a module back in, your changes are merged with any changes other developers have made since you checked the module out.
The first step you must take when you decide to place an object under SourceSafe control is to add the host database to SourceSafe. You can then begin to check objects in and out and to use the product's features. The following sections explain in more detail how to work with Visual SourceSafe.
When you're ready to place an application under SourceSafe control, take the following steps:
Choose Tools | SourceSafe | Add Database to SourceSafe.
A dialog box opens, indicating that Visual SourceSafe must close the database before it can be placed under SourceSafe control. (See Figure 28.1.) Click Yes to continue.
The Add SourceSafe Project dialog box appears. (See Figure 28.2.) The name of the database is selected as the name for the SourceSafe Project.
Click OK to accept the project name. You're then prompted to create the project. (See Figure 28.3.)
Click Yes to create the project; this opens the Add Object(s) to SourceSafe dialog box. (See Figure 28.4.) Here you can determine which database objects you want to place under SourceSafe control. By default, each object in the database is selected. You can deselect specific objects or deselect all objects, then select just the objects you want. When you're done, click OK.
SourceSafe notifies you as it exports each object to SourceSafe. (See Figure 28.5.) When it's done, the warning shown in Figure 28.6 tells you that you don't have the Data and Misc. objects checked out. This means that any changes you make to local tables are lost the next time you check out or get the latest version of these objects.
Click OK to complete the process. Looking at the Database window, you should see that each object has a lock that remains until you have checked out an object. (See Figure 28.7.)
Once you add a database to SourceSafe control, the SourceSafe submenu expands to include many options needed to manage a SourceSafe project. (See Figure 28.8.) These options are covered throughout the remainder of this chapter.
Figure 28.8. The Visual SourceSafe menu gives you several options for managing a Visual SourceSafe project.
Each query, form, report, macro, and module is stored as a separate text file in Visual SourceSafe. When you add an object to SourceSafe control, it's exported to a text file and copied into the Visual SourceSafe project. When you check out an object, it's copied to a temporary location on your machine and then imported into the Access database on your machine as a query, form, report, macro, or module.
All other database objects (tables, relationships, command bars, database properties, startup properties, import/export specs, VBA project references, the VBA project name, and conditional compilation arguments) are stored in one Access MDB file that Visual SourceSafe treats as a binary file. These objects can't be checked out individually.
As mentioned, all queries, forms, reports, macros, and modules are stored as text files and the rest of the objects are stored in one binary file. Table 28.1 shows each object type and the extension the object is stored with when it gets added to Visual SourceSafe.
The developer who adds a database to SourceSafe can continue to work on the original copy. Other developers who want to work on the application must create their own local copies of the database. To do that, follow these steps:
Choose Tools | SourceSafe | Create Database from SourceSafe Project from the menu to open the Open SourceSafe Project dialog box. (See Figure 28.9.)
Select a project and click OK. You're prompted for a directory where your local copy of the database will be placed.
Select a directory and click OK; this returns you to the SourceSafe project dialog box.
Click OK to create the database. When Access is done creating the local objects, the Source Code Control Results window says
Completed. (See Figure 28.10.)
Once a database has been added to Visual SourceSafe, you can't modify any of the objects you designated as controlled by SourceSafe without first checking them out. You check out the objects you want to modify, make changes to them, and check them back in when you're done. The easiest way to check out a single object is to right-click it and select Check Out. If you want to check out multiple objects, choose Tools | SourceSafe | Check Out; this opens the Check Out Object(s) from SourceSafe dialog box. (See Figure 28.11.) Here you can select all the objects you want to check out. When you return to the Database window, the objects you checked out have a checkmark next to them. (See Figure 28.12.)
Figure 28.11. Use the Check Out Object(s) from SourceSafe dialog box to designate which database objects you want to check out.
Figure 28.12. The Database window adds an icon to show which objects in a database have been checked out.
If you try to modify the design of an object that is not controlled by Visual SourceSafe, you don't get any error messages, so everything proceeds as usual. On the other hand, if you try to modify the design of an object that is controlled by Visual SourceSafe but hasn't been checked out, the error message in Figure 28.13 appears. As you can see, you're given the choice of checking out the object, opening the object as read-only and not checking it out, or canceling.
Figure 28.13. The error message you see when you try to modify the design of an object that hasn't been checked out.
You can check in one object or check in several objects simultaneously. To check in objects, right-click any object that's checked out and select Check In; this opens the Check In Object(s) to SourceSafe dialog box. (See Figure 28.14.) Click to select any objects you want to check in, then click OK. The objects you checked in once again appear in the Database window with a lock, indicating that they can't be modified without being checked out.
While you're working on the database, the objects in your local copy might not be updated with changes other users have made to the objects. To see these changes, you must get the object's latest version from the SourceSafe project. To do this with one object, right-click the object and select Get Latest Version; for multiple objects, choose Tools | SourceSafe | Get Latest Version. The Get Object(s) from SourceSafe dialog box appears, allowing you to select the objects you want.
Depending on how you have configured Visual SourceSafe, you might be prompted to add new objects to SourceSafe control. If you add objects to your database and don't place them under SourceSafe control, you can always opt to add them later. To do this, choose Tools | SourceSafe | Add Object(s) to SourceSafe. The Add Object(s) to SourceSafe dialog box opens, showing you all the objects in your local database that haven't been added to SourceSafe control.
Not only does Visual SourceSafe help to manage the process of several developers working on an application simultaneously, but it also helps you manage versions of your application. It does this by showing you the differences between the checked-out version of an object and the version stored in the Visual SourceSafe project, by allowing you to view an object's history, and by letting you revert to an object's previous version.
One of the more powerful aspects of Visual SourceSafe is its ability to show the differences between the checked-out version of an object and the version in the SourceSafe project. These differences show you what you've done since you checked the object out. To view the differences, choose Tools | SourceSafe | View Differences. The Differences window opens, which lets you easily jump from difference to difference within the object. Deleted lines are blue, changed lines are red, and added lines are green.
Often, it helps to view everything that's transpired in an object; for example, you might want to see who checked out each object and when. To see an object's history, first click to select the object, then choose Tools | SourceSafe | Show History. The History of File dialog box opens, which shows you the versions of the object, who performed each action on the object, the date the action was performed, and what the action was. From the History of File dialog box, you can do the following:
View each version of the object
See the details of each action taken on the object
Get the object's current version from the Visual SourceSafe project
See the differences between two versions of the object
Pin a specific version of a file to the current project
Roll back to a previous version of the object
Get a report of everything that has transpired with the object
Visual SourceSafe also gives you the ability to roll back to previous versions of an object. This is particularly useful if things have gone seriously awry and you want to start over in a version where conditions were more stable. You can revert to an object's previous version from the History of File dialog box. Select the version you want to roll back to and click Rollback. You're warned that your actions are irreversible. If you select Yes, the object is rolled back to the selected version.
Visual SourceSafe alters Access's behavior; the following sections explain these changes so they don't take you by surprise.
Before you distribute a database, you should always compact it. When you try to compact a database that's under SourceSafe control, you're asked whether you want to remove the database from SourceSafe control. When you respond Yes, Access goes through each object in the database and removes all SourceSafe properties.
When you open a database that's under SourceSafe control, it's always opened exclusively. This prevents more than one developer from modifying objects in the local database at a given time.
When you open a database, you can opt to have Access automatically refresh all objects from the SourceSafe project, you can be prompted on whether you want to refresh all objects, or you can opt not to have Access automatically refresh any objects. To modify this option, choose Tools | SourceSafe | Options and use the “Get latest checked in version of objects when opening a database” drop-down list to designate your choice.
When closing a database, you can choose to have Access automatically check in all objects, to prompt you on whether you want to check in all objects, or not to have Access check in any objects. This option is found under Tools | SourceSafe | Options. Use the “Check in objects when closing the database” drop-down list to select your choice.
Each time you check out an object, Access determines whether it has been checked out already. If the object hasn't been checked out by another user, you're asked whether you want to check it out. If you respond No, Access opens the object as read-only. If the object has been checked out by another user, and it's a module, you're warned that another user has the object checked out and you get the option of checking the object out. Your changes will be merged with the other user's changes later. If you try to check out any object other than a module, and it has already been checked out by another user, you're warned that you can just view the object as read-only in Design view.
When you save a new object, or choose File | Save As for an existing object, you can designate whether the new object is placed under SourceSafe control by choosing Tools | SourceSafe | Options. You can have Access automatically place the object under SourceSafe control, you can have Access prompt you for your choice, or you can tell Access not to place the object under SourceSafe control. Use the “Add objects to source control when adding them to Microsoft Access” drop-down list to make your selection.
When you rename an object that's under SourceSafe control, Access automatically reflects the name change in the source control project. An object can't be renamed while checked out by another user.
When you delete an object, you can have Visual SourceSafe display a message box asking whether you want to remove the object from the SourceSafe project, you can have Access automatically remove the object from the SourceSafe project, or you can opt for Access not to remove the object from the SourceSafe project. This option can be configured by choosing Tool | SourceSafe | Options in the “Remove objects from source control when deleting them from Microsoft Access” drop-down list.
Although Visual SourceSafe is a powerful product, it does impose some limitations you should be aware of. Only Access 97 databases can be placed under Visual SourceSafe control, and user and group permissions can't be set when an object is under SourceSafe control. In fact, when you add a database to SourceSafe control, all user and group permissions are removed! Furthermore, you can't put replicated databases under source code control, and you can't move, rename, or copy the local version of the database and continue working with it under SourceSafe control. To move a database, you must first check in all objects, delete the local database, and then recreate it in the new location.
There are two reasons why you might want to place the Time and Billing application under SourceSafe control. First, multiple developers may be working on the project; second, you may want to keep track of changes made to each object to reserve the option of rolling back to a previous version of an object.
Visual SourceSafe is a powerful product for both the individual developer and members of a development team. It helps you manage group development and versioning of the objects in a database. Furthermore, it integrates seamlessly with Microsoft Access 97 and is fairly easy to use. In my opinion, most, if not all, Access databases should be placed under SourceSafe control while they're being developed.