ACC1x: Using SHARE.EXE and VSHARE.386 with Microsoft Access

• Microsoft Access versions 1.0, 1.1

SUMMARY

MS-DOS, Microsoft Windows, and Windows-based applications use SHARE.EXE to provide a file locking mechanism so that Windows-based tasks can communicate with each other. The tasks use SHARE.EXE to sort out file read/write conflicts. Therefore, it is important that you load SHARE.EXE before starting Windows. Without SHARE.EXE loaded, you may experience data corruption in applications.

Using SHARE.EXE with Microsoft Access allows multiple users to access a database at the same time while protecting them from updating the same record at the same time. If a database is opened exclusively by one user, no other users will be able to use the database until the first user releases it. However, if all users open the database in a shared mode, SHARE.EXE allows all users to read and write to the database simultaneously, with the exception of locked records. For example, if a user has record 100 open on a particular database, that record is considered locked, and no other users will be able to change any data in record 100 until the first user finishes changing it.

For this reason, while it is possible to run Microsoft Access without first loading SHARE.EXE, Microsoft does not recommend it. If you choose not to use SHARE.EXE, you must ensure that only one Windows-based task writes to a database record at any given moment.

MORE INFORMATION

MS-DOS uses SHARE.EXE to lock files as requested by applications. SHARE.EXE controls updates and prevents data corruption in files.

An application can request a deny-read lock (exclusive), a deny-write lock, or both. Deny-write locks allow other applications to read data, but prevent two different applications from updating the same file at the same time.

SHARE.EXE also provides byte-range locks. When a range of bytes is locked, other applications cannot read, write, or lock those bytes. Other, unlocked bytes, in the file are not affected. An application can use byte-range locks to place exclusive locks on records for record-level locking.

In single-user environments, SHARE.EXE prevents file contention accidents when multiple instances of a program attempt to write to the same database or database record at the same time. In multiple-user environments such as networks, SHARE.EXE prevents possible database corruption when several different network users attempt to write to the same database or database record at the same time.

Microsoft Windows for Workgroups

The only time you do not have to use SHARE.EXE is when you run Microsoft Windows for Workgroups in Enhanced mode. Microsoft Windows for Workgroups in Enhanced mode loads and uses a file-sharing program called VSHARE.386, which is a replacement for SHARE.EXE. There is an entry for VSHARE.386 in the SYSTEM.INI file.

If you plan on running Windows for Workgroups exclusively in Enhanced mode and do not run other applications that require SHARE.EXE, you can save approximately 5K of conventional memory by not loading SHARE.EXE. To do this, remove the SHARE.EXE line from your AUTOEXEC.BAT file and restart your computer.

SHARE.EXE is likely to be in your AUTOEXEC.BAT file because during the Microsoft Access installation process, the SETUP.EXE program automatically inserts the following MS-DOS command in your AUTOEXEC.BAT file:

   <MS-DOS directory>\SHARE.EXE /L:500

Microsoft Access runs correctly with either SHARE.EXE or VSHARE.386, but SHARE.EXE limits the number of available locks to the number specified when SHARE.EXE was loaded. The /L parameter specifies the number of share locks; the default is 20. VSHARE.386, on the other hand, dynamically allocates the number of locks available based on the demand for locks. The number of locks available is especially important if the computer running Microsoft Windows for Workgroups acts as a server in a client-server environment.