ACC2: How Microsoft Access Uses SHARE.EXE

This article was previously published under Q113355
This article has been archived. It is offered "as is" and will no longer be updated.
Advanced: Requires expert coding, interoperability, and multiuser skills.

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

Description of SHARE.EXE

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

In MS-DOS, Share is a terminate-and-stay-resident (TSR) utility. If you arerunning Windows for Workgroups version 3.11 in enhanced mode, Share isreplaced 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 onlyVShare, you can conserve memory by not loading Share. Consult your Windowsfor 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 fromaccessing the same file (or region of a file) at the same instant. OnceShare is run, an application can use it to lock a file (or region of afile) so that only one person at a time can make changes to it, preventingfile read and write conflicts. Most multiuser and network software packagesuse Share for their file and record locking tasks.

Microsoft Access uses Share to control file sharing between two or moreinstances of Microsoft Access running on the same system and using the samedatabase, or to allow a workstation to run as a non-dedicated file serverin a Windows for Workgroups environment. Share is also used by certainobject linking and embedding (OLE) applications. OLE applications use Shareto coordinate file usage, and OLE itself opens files using Share. Also, allof 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 beenopened, plus an internal file handle number and other housekeepinginformation. The LOCK table contains a list of internal file handle numbersand corresponding information on the various areas of each file that arelocked. Share checks these tables whenever an application attempts to openor use a file or a region of a file, and tells the application whether ornot 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 needsfor its internal tables. You can control the size of Share's internaltables with two command line options: /F and /L. The /F option controls theamount of space allocated for the FILES table and the /L option controlsthe number of simultaneous locks that Share will allow.

The /F Parameter

The /F parameter controls the size (in bytes) of the table that Sharereserves 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 theother applications loaded). The default is /F:2048 (or, 2K). Share storesthe complete pathname of each file, plus 11 bytes of file handle andhousekeeping information. You can figure the largest possible spacerequirement by multiplying the number of files in your CONFIG.SYS file by71 (60 bytes for the longest possible pathname + 11 bytes for otherinformation). For example, if your system has FILES = 255 in yourCONFIG.SYS file, in the worst case (all 255 files are open) Share wouldrequire over 18,100 bytes for the FILES table.

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

The /L Parameter

The /L parameter controls the number of simultaneous locks that Share canhandle. A low number of Share locks is a common problem for MicrosoftAccess users on networks. The syntax for the /L parameter is
   SHARE /L:<n>				

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

Opening a file on a server requires at least one lock. In addition, mostnetwork programs use several more locks per file. They lock individualrecords, and even individual fields within records. Most multiuserdatabases use many locks--sometimes 10 or more per file. On a network, withseveral users opening each file, Share's 20-lock default can be used upalmost instantly. The number of Share locks used by Microsoft Accessvaries, depending on the amount of data that is accessed. A rough estimateof the number of locks needed is 5 times the number of records that will beaccessed at any given time. During the Microsoft Access installationprocess, the SETUP.EXE program automatically sets the number of locks to500.

Use the /L parameter to increase the number of locks allowed to preventShare lock errors. The /L setting should be at least the number of filesyou have specified in your CONFIG.SYS file. If you are running a multiuserprogram that opens many files, consider setting /L to at least twice thenumber of open files allowed, or in the case of Microsoft Access, 5 timesthe 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.
For more information about setting the parameters for share.exe, please seethe following article in the Microsoft Knowledge Base:

112125 ACC2: Using SHARE.EXE and VSHARE.386 with Microsoft Access 2.0
mu multiuser sharing

Article ID: 113355 - Last Review: 01/09/2015 05:03:49 - Revision: 1.0

  • Microsoft Access 2.0 Standard Edition
  • kbnosurvey kbarchive kbinfo kbusage KB113355