This documentation is archived and is not being maintained.

Best Practices for Preventing Data Corruption

Visual Studio 2005

Microsoft Visual SourceSafe furnishes optimal storage and security for your current data and past versions, under typical operating conditions. However, as with any database product, data corruption can occur. The most common reasons for data corruption are:

  • General network problems, for example, an unreliable remote connection causing Visual SourceSafe to drop communication midway through a file check-in.

  • Running out of disk space.

Running the Latest Version of Visual SourceSafe

Microsoft periodically releases service packs for that correct known issues with certain applications. We recommend that you install the service packs as soon as possible. Customers who want to upgrade their Visual SourceSafe client to the latest service pack releases should use the service pack installations instead of running the Visual SourceSafe Setup program again.

Sizing a Database to Reduce Data Corruption

Under typical use, your Visual SourceSafe database should not exceed 3 to 5 GB. To determine an appropriate size, consider the amount of free space on the server, the relationship among the projects being stored, the amount of file history you need to access quickly, and user tolerance for decreased performance. Visual SourceSafe does not limit the number of databases you can put on a server. For more information, see How to: Reduce the Size of a Database.

Analyzing the Database Frequently

To minimize data corruption, it is recommended to run the ANALYZE utility regularly. This utility checks for and repairs many common data write errors. Run ANALYZE on your Visual SourceSafe database together with your regular tape backup schedule to ensure the stability and security of your data. See How to: Find and Repair Data Corruption.

Keeping Disk Space Available for the Database

Visual SourceSafe checks for disk space when performing database operations. Because of performance concerns, however, it does not look for space on every disk write. To avoid possible database corruption, make sure there is enough free disk space on the server or remote database computer so that a complete copy of the database can be created during typical ANALYZE operations. For more information, see ANALYZE Utility.

Caution noteCaution

Do not allow Visual SourceSafe or the ANALYZE utility to run out of disk space while it is running. Running out of disk space in the middle of a complex operation can create serious database corruption.

To help keep disk space available, limit the use of the Visual SourceSafe branch feature. It is advisable to avoid branching across top-level projects, because these operations complicate project archival and restoration into another database from an archive. When you branch files and then delete them, the space is not recovered until all copies of the branched file in the database are destroyed.

To reduce data loss resulting from problems with hard disk access, consider using RAID technology in your team environment. RAID is a fault-tolerant disk configuration in which part of the physical storage capacity contains redundant information about the data stored on the disks. You can regenerate the data using this redundant information if one of the disks or the access path to it fails, or if a sector on the disk cannot be read.

Maintaining File Integrity

The Ss.ini files for Visual SourceSafe database users are limited to 64 KB and a maximum of ten different computer-specific settings. Every time that a user logs in from a different computer, the Ss.ini file saves the window positions and other computer-specific information. If you are experiencing unusual user-specific data corruption problems, try deleting unnecessary entries in the user's Ss.ini file.

Another thing that you can to do to maintain file integrity is to ensure that all users have their own working folders for all projects. When multiple users share a working folder, a file checked out by one user can be modified by anyone with access to that folder. Maintaining separate working folders ensures that users modify only files they have personally checked out.

Keeping Operations Synchronized When Using Older Versions

If you run in a mixed client environment, for example, some clients are running Visual SourceSafe version 8.0 and some are running earlier versions, you will have to synchronize the older client system clocks with the database server system clock.

In earlier versions, check-in and check out operations for a database can appear to be out of sequence, affecting database labels and version control. Synchronizing dates and system clocks is especially important when users from different time zones must access the same database and will get a time reference from the database computer.

Make sure that you synchronize the dates and system clocks for all Visual SourceSafe client computers with the Visual SourceSafe server. If desired, you can set up a computer that is running Windows NT Server to act as a Domain Time Source server for users to synchronize their local date and time with the network.

Limiting Database Copies and Moves

To avoid data corruption when you copy or move a database, ensure that all users are disconnected. For these operations, limit yourself to archiving the old database, creating a new database, and then restoring the old files to the new database.

Forcing Web Service Access

To reduce data corruption, you might want to configure your environment so that users can only connect to the database through Web service, using SourceSafe Internet plug-ins in Visual Studio.

Using the Appropriate Software

When you use Visual SourceSafe in an IDE, be sure to use the Visual SourceSafe package appropriate to the IDE, for example, a SourceSafe plug-in in Visual Studio. For example, do not check out and check in files from both Visual SourceSafe Explorer and source control in Visual Studio. Visual SourceSafe and an IDE view data files very differently. Checking out only one file in Visual SourceSafe Explorer instead of the appropriate plug-in can cause the database files to become unsynchronized and therefore corrupted in the IDE.

Preventing Power Outages

Much data loss and loss of service can be attributed to power outages. To minimize this kind of problem, it is recommended to use an uninterruptible power supply (UPS) for your site.

See Also