ACC2: How Microsoft Access Uses SHARE.EXE

ID: Q113355

The information in this article applies to:

SUMMARY

Advanced: Requires expert coding, interoperability, and multiuser skills.

This article describes the SHARE.EXE file-sharing utility, and how it is used by Microsoft Access to handle file sharing for multiuser databases.


MORE INFORMATION

Description of SHARE.EXE

SHARE.EXE (Share) is a file-sharing utility included with MS-DOS versions 3.0 and higher. It is used by application programs that work with several files at a time. It is essential for sharing files on a network with multiple users.

In MS-DOS, Share is a terminate-and-stay-resident (TSR) utility. If you are running Windows for Workgroups version 3.11 in enhanced mode, Share is replaced by an enhanced mode virtual device driver (VxD) called VSHARE.386 (VShare). VShare was designed for Windows for Workgroups and the peer-to- peer networking it supports. Since Windows for Workgroups 3.11 uses only VShare, you can conserve memory by not loading Share. Consult your Windows for Workgroups documentation for more information about using VShare.

Because Share and VShare are functionally identical for Microsoft Access, only Share will be described further in this article.

Share gives applications an easy, well-defined way to prevent users from accessing the same file (or region of a file) at the same instant. Once Share is run, an application can use it to lock a file (or region of a file) so that only one person at a time can make changes to it, preventing file read and write conflicts. Most multiuser and network software packages use Share for their file and record locking tasks.

Microsoft Access uses Share to control file sharing between two or more instances of Microsoft Access running on the same system and using the same database, or to allow a workstation to run as a non-dedicated file server in a Windows for Workgroups environment. Share is also used by certain object linking and embedding (OLE) applications. OLE applications use Share to coordinate file usage, and OLE itself opens files using Share. Also, all of the installable ISAM drivers rely on Share.

How Share Works

Share maintains two tables in memory: the FILES table and the LOCK table. The FILES table contains the complete pathname of each file that has been opened, plus an internal file handle number and other housekeeping information. The LOCK table contains a list of internal file handle numbers and corresponding information on the various areas of each file that are locked. Share checks these tables whenever an application attempts to open or use a file or a region of a file, and tells the application whether or not the file or region is available.

Share uses at least one entry in each table for each file that is opened. The more files your computer opens and locks, the more space Share needs for its internal tables. You can control the size of Share's internal tables with two command line options: /F and /L. The /F option controls the amount of space allocated for the FILES table and the /L option controls the number of simultaneous locks that Share will allow.

The /F Parameter

The /F parameter controls the size (in bytes) of the table that Share reserves for filenames and handles. The syntax for the /F parameter is 

   SHARE /F:<n>

where <n> is any number from 0 to approximately 62,000 (depending on the other applications loaded). The default is /F:2048 (or, 2K). Share stores the complete pathname of each file, plus 11 bytes of file handle and housekeeping information. You can figure the largest possible space requirement by multiplying the number of files in your CONFIG.SYS file by 71 (60 bytes for the longest possible pathname + 11 bytes for other information). For example, if your system has FILES = 255 in your CONFIG.SYS file, in the worst case (all 255 files are open) Share would require over 18,100 bytes for the FILES table.

On a network server, you must allocate enough space for all the files that will be opened by all the users on the network. The default value is 2048 bytes--enough space to hold the information for 66 files with paths averaging 20 characters, or about 28 files in a worst-case scenario. If you know that paths on your system average more than 20 characters or that you will be opening many files, you should use the /F parameter to give Share more space for the FILES table.

The /L Parameter

The /L parameter controls the number of simultaneous locks that Share can handle. A low number of Share locks is a common problem for Microsoft Access users on networks. The syntax for the /L parameter is 

   SHARE /L:<n>

where <n> is an integer between 1 and approximately 3800 (depending on the size of other applications loaded). The default is 20 locks.

Opening a file on a server requires at least one lock. In addition, most network programs use several more locks per file. They lock individual records, and even individual fields within records. Most multiuser databases use many locks--sometimes 10 or more per file. On a network, with several users opening each file, Share's 20-lock default can be used up almost instantly. The number of Share locks used by Microsoft Access varies, depending on the amount of data that is accessed. A rough estimate of the number of locks needed is 5 times the number of records that will be accessed at any given time. During the Microsoft Access installation process, the SETUP.EXE program automatically sets the number of locks to 500.

Use the /L parameter to increase the number of locks allowed to prevent Share lock errors. The /L setting should be at least the number of files you have specified in your CONFIG.SYS file. If you are running a multiuser program that opens many files, consider setting /L to at least twice the number of open files allowed, or in the case of Microsoft Access, 5 times the number.

Questions and Answers About Share and Microsoft Access


  1. Q: Does Microsoft Access use Share if you open a database exclusively?

    A: Yes. Share takes over all File Open calls.


  2. Q: Do any of the ODBC drivers (such as those in the Drivers Pack, or third-party drivers) require Share?

    A: Yes, all of the ODBC drivers require Share, whether in a multiuser or a stand-alone configuration.


  3. Q: What is the highest number of locks Microsoft Access might need?

    A: This is impossible to determine exactly, since it depends on the amount of data that is accessed at any given time. However, a rough estimate is 5 times the number of records that will be accessed at any given time.


  4. Q: What memory does Share use?

    A: Share uses conventional memory, while VShare uses memory from the Windows memory pool (extended, virtual, and so on). You do not need to run both Share and VShare, because VShare disables Share.


  5. Q: Do Share and VShare compete with other applications for memory?

    A: Share is an MS-DOS application that is loaded into the conventional memory area, so it does compete with other programs that use conventional memory. Also, Share requires a small amount of memory to store file and lock information. VShare is a Windows-managed VxD, so it can be allocated in any of the available Windows memory areas and does not impact other applications.


  6. Q: Do transactions use Share?

    A: Yes.


  7. Q: Why do I sometimes get a "Share locks exceeded" message, while at other times I get an "Out of memory" error message?

    A: If you have a Share locking problem, you get an error message identifying Share as the problem. An "Out of memory" message can be caused by a number of other things.



REFERENCES

For more information about setting the parameters for share.exe, please see the following article in the Microsoft Knowledge Base:

Q112125 ACC2: Using SHARE.EXE and VSHARE.386 with Microsoft Access 2.0

Additional query words: mu multiuser sharing 


Keywords          : kbusage GnlMu 
Version           : 2.0
Platform          : WINDOWS 
Issue type        : kbinfo

Last Reviewed: April 3, 1999