Article ID: 113355 - View products that this article applies to.
This article was previously published under Q113355
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.
Description of SHARE.EXESHARE.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 WorksShare 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 ParameterThe /F parameter controls the size (in bytes) of the table that Share reserves for filenames and handles. The syntax for the /F parameter is
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 ParameterThe /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
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
For more information about setting the parameters for share.exe, please see the following article in the Microsoft Knowledge Base:
(http://support.microsoft.com/kb/112125/EN-US/ )ACC2: Using SHARE.EXE and VSHARE.386 with Microsoft Access 2.0
Article ID: 113355 - Last Review: November 6, 2000 - Revision: 1.0