Author: David Caldwell
Last saved by: Janet Manuel

Chapter 11 : Networking and FoxPro
Microsoft FoxPro Support Engineers
Microsoft Corporation
Created: December 15, 1993
Abstract
The following text concerns Networking Microsoft FoxPro for Windows version 2.5x and contains the following:
•	Introduction
•	DBF Compatibility
•	NETBIOS Compatibility
•	Configuration for a Network
•	File and Record Locking
•	Networking Commands
•	Network Tips and Tricks
•	Additional Information
Introduction
Beginning with FoxPro 2.5, all FoxPro products ship network compatible. There is no need to buy a separate product to handle shared databases. This section will discuss various networking issues with FoxPro for Windows.
DBF Compatibility
FoxPro version 2.5x for Windows has the ability to share databases between different versions of FoxBASE and FoxPro including FoxBASE for the Macintosh, FoxBASE Multi-user 1.0x, FoxPro LAN 1.0x, FoxPro LAN 2.0 and 2.5x for MS-DOS
It is important to note that FoxPro version 2.5x does not respect EXCLUSIVE use of a file by FoxBASE for the Macintosh. RECORD and FILE locks are still respected. All versions of FoxBASE are unable to use FoxPro memo fields. If a database with memo fields is to be used between platforms the following command will convert the database to a format that is accessible by both FoxPro and FoxBASE platforms:
COPY TO <newdbfname> TYPE FOXPLUS
Fox's ability to share files across not only platforms but products (FoxPro/FoxBASE) allows an extensive number of machine combinations to access the same data with a similar user interface.
NETBIOS Compatibility
NETBIOS compatibility is still desired to ensure accurate reporting of record and file locking, exclusive use of files and printing error messages. All commands and functions may work adequately without NETBIOS compatibility or NETBIOS available and running on the network, but intermittent failures may occur. Some of these failures may include the following:
•	Collisions of RECORD and/or FILE locking. Stations do not respect locks of other stations.
•	Failure to respect or report EXCLUSIVE use of files.
•	Failure to return printing error messages and to release print jobs.
•	Inaccurate printing error messages.
Configuration for a Network
The CONFIG.FPW file is the most powerful tool to affect how FoxPro performs in a networked environment. The configuration file allows redirection of temporary files from the Windows temporary directory to any directory. FoxPro will run more efficiently if temporary files are stored on a local drive as opposed to being stored on a network drive. This configuration reduces the demands on the network services and traffic.
In addition, each user’s configuration file may contain a pointer to their own resource file. Individual CONFIG.FPW files for each user are referenced through the FOXPROWCFG MS-DOS environment variable.
NOTE:     See the Configuration section in this Resource Kit for the appropriate uses of the CONFIG.FPW file for network configurations.
File and Record Locking
FoxPro provides mechanisms for both file and record locking on databases as well as the ability to use databases exclusively. This section will discuss the following topics:
•	Types of Locking
•	Lock Processing
•	Multi-locking
•	Locking and the Screen Generator
Types of Locking
There are two types of locks implicit and explicit.
Implicit Locking
Implicit record locks occur automatically when there is an attempted change to a record in the database. If an implicit lock is permitted, changes are allowed to continue. If the lock is not successful, the value of reprocess is checked to determine what action to take. 
There is no need to create code to unlock the record after an implicit lock because FoxPro automatically unlocks the record when the record pointer is moved. This type of locking does not permit locking multiple records.
Explicit Locking
Explicit record locks occur when LOCK() or RLOCK() functions are issued. Unlike implicit locks, records locked by these functions do not automatically unlock when the record pointer is moved. This type of locking gives the programmer complete control over the record management process, including the ability to apply locks to multiple records. Unlike implicit locks, explicit locks must be UNLOCKed.
Lock Processing
When an attempt is made to implicitly or explicitly lock a record, FoxPro checks the status of the database at the server. If the .DBF is sharable and not opened exclusively, and this particular record is not locked, the lock is successful and the user may make changes to the data. If an implicit or explicit lock is unsuccessful, the value of SET REPROCESS is used to determine how to continue. The default for SET REPROCESS is 0. This gives the message, “Attempting to lock... Press ESC to cancel”. Pressing escape on an implicit lock returns the following dialog:

This dialog also appears when REPROCESS is set to AUTOMATIC or set to a numeric time-out value. This dialog does not appear in situations where an ON ERROR routine is in effect or when REPROCESS is set to -1. In that situation, no processing occurs until the lock is successful.
If an explicit lock using RLOCK() is successful, the function returns true (.t.). If the lock is unsuccessful, RLOCK() will return false (.f.). In the case of explicit locking, a dialog does not come up when the lock is not successful.
Multi-locking
Another useful multi-user function is the ability to create multiple file and record locks. This allows you to set aside a range of records that need to be locked to prevent other workstations from modifying them. This provides the ability to lock a record range instead of the entire file. Although performing a single file lock is faster than performing multiple record locks, a file lock prevents multiple users from accessing any records in the file. An UNLOCK command releases all of the locks in a multi-lock situation.
Locking and the Screen Generator
When Screen Builder tool is used, the default action is to generate a locking READ. If you are using @..GETs from the database field name, it is possible that the first person running the application could lock subsequent users out, because they are pointing to the first record of the database. You can select a READ NOLOCK option to avoid this. In the Generate Screen dialog box, choose the More push button and select the READ NOLOCK option.
If a READ NOLOCK is used, an option would be need to give the user the ability to lock a record for editing.
Networking Commands
This section discusses the following network commands:
•	NETWORK()
•	SET REPROCESS
•	SET REFRESH
•	SYS(0)
•	SET EXCLUSIVE
•	SET MULTILOCKS
•	LOCK() and RLOCK()
•	UNLOCK
NETWORK()
In FoxPro version 2.0, the NETWORK() function was used to determine if the LAN version of FoxPro was running. The NETWORK() function still returns a value in FoxPro 2.5 for compatibility reasons, but that value is always true (.t.).
SET REPROCESS
SET REPROCESS TO <expN> [SECONDS] | TO AUTOMATIC
At times, a record or file may be locked by another user. SET REPROCESS specifies how many times (or for how long) FoxPro attempts to lock a file or record after an unsuccessful locking attempt.
SET REFRESH
SET REFRESH TO <expN1> [, <expN2>]
When tables are opened for shared use on a network, it is possible that records you are viewing are being edited by other users. SET REFRESH allows open BROWSE windows to be updated based on the parameters specified.
SYS(0)
SYS(0) returns the machine number and machine name when using FoxPro in a network environment. A machine number and name should be assigned by the network software when the network shell is loaded. If a machine number or name has not been assigned or the network shell has not been loaded, SYS(0) returns a character string consisting of 15 spaces, a pound sign (#) followed by another space and then 0. Consult your network manual for further information on defining a machine number and name. SYS(0) returns 1 when using FoxPro in a stand-alone environment.
SET EXCLUSIVE
SET EXCLUSIVE ON|OFF
SET EXCLUSIVE specifies whether FoxPro opens a table/.DBF files for exclusive or shared use on a network and must be set before opening the databases that you want it to affect. The default for SET EXCLUSIVE is ON.
A file can also be opened on a network for exclusive use by including EXCLUSIVE with the USE command. It is not necessary to perform record or file locking on a table/.DBF opened for exclusive use. 
Some commands which require EXCLUSIVE use are :
•	INSERT
•	INSERT BLANK
•	MODIFY STRUCTURE
•	PACK
•	REINDEX
•	ZAP
If a table/.DBF is opened on a network when SET EXCLUSIVE is OFF, the table/.DBF can be shared and modified by any user on the network.
SET MULTILOCKS
SET MULTILOCKS ON | OFF
When a table/.DBF is opened for shared use on a network, the MULTILOCKS setting determines whether you can attempt to lock either a single record or a set of records. Records can be locked with the LOCK( ) or RLOCK( ) function.
Toggling MULTILOCKS from ON to OFF or from OFF to ON implicitly issues UNLOCK ALL releasing record and file locks in all work areas.
The default value for SET MULTILOCKS is OFF.
LOCK() and RLOCK()
(R)LOCK([<expN> | <expC1>] | [<expC2>, <expN> | <expC1>])
LOCK( ) and RLOCK( ) are identical. If the lock or locks are successfully placed, a true (.t.) value is returned. Locked records are available for both read and write access to the user who placed the locks; any other user has read-only access to the locked record(s). 
Executing LOCK( ) doesn't guarantee that the record lock or locks will be successfully placed. A record lock cannot be placed on a record already locked by another user or in a table/.DBF locked by another user. If the record lock or locks can't be placed for any reason, a false value (.f.) is returned.
UNLOCK
UNLOCK [IN <expN> | <expC> | ALL]
Only the user that issues the locks may UNLOCK the records or the table/.DBF. UNLOCK cannot unlock a table/.DBF opened for exclusive use. All locks (whether for records or for the file) are released from the table/.DBF in the current work area if you issue UNLOCK without arguments. If there are related tables/.DBFs, issuing an UNLOCK does not release locks from the related records or files. You must explicitly release the record or file locks in each of the related files. You can release all locks on every opened table/.DBF by issuing an UNLOCK ALL.
Network Tips and Tricks
This topic contains some tips for FoxPro for Windows in a networked environment.
Rebuild .CDX Files
Occasionally, you will need to rebuild .CDX files. This can reduce the .CDX file size, thereby improving performance. When recreating .CDX tags, you should first remove the tags using the DELETE TAG ALL command.
You can also delete the structural .CDX file. When you open the database FoxPro will inform you that the structural CDX is not found. It is safe to ignore that message and recreate the index.
Pack Tables and Memo Files
PACK your tables periodically. This will reduce the size of the tables and improve performance. Using the PACK MEMO command reduces size of associated memo files. This is especially helpful for tables in which you frequently make changes to memo fields.
Recycling Records
In a multi-user environment, it may be difficult to obtain exclusive use of the file for PACKing. If the file is not PACKed, the amount of disk space required to store deleted records will continue to grow. To work around this problem, you can recycle deleted records by using the technique illustrated below.
The following code snippets blank out all fields in the record when a record is deleted from the file. When an attempt is made to append a new record to the database, the program first checks to see if any blank deleted records are available. If a deleted record is available, the program uses the record to store the new data. If a deleted record is not available, the program appends a blank record. 
IF LOCK()
	SCATTER MEMVAR MEMO BLANK	&See note below on memo fields.
	GATHER MEMVAR MEMO
	DELETE
ENDIF
This code snippet either recycles a deleted record or appends a new blank record:
LOCATE FOR DELETED()
IF EOF()
	APPEND BLANK
ELSE
	RECALL
ENDIF
Unused space in memo files will not be recycled. To recover unused space in memo files, you must issue a PACK MEMO command.
Peer to Peer Networks
The following items are the suggested configuration settings for many Peer to Peer Networks
1.	Make sure that you have the latest version of the network drivers and shells from your vendor. Often these patches are made available from the vendor through their BBS or CompuServe.
2.	The FoxPro .EXEs, .ESLs, have to be marked read-only.
NOTE:     A good rule to follow here is, unless the file is something the user needs to update (i.e.: .DBF’s, .FPT’s, .CDX’s), mark the file READ-ONLY.
3.	Set FILES=99 in the server CONFIG.SYS file.
4.	Loading the server software in conventional memory can cause FoxPro to run slowly. To free up as much conventional memory as possible, load the network drivers high if possible.
5.	You do not need to load NETBIOS. (See the section regarding NETBIOS for more information.)
6.	Redirecting the net programs to NUL on startup can cause a "Too Many Files Open" error. Since the server programs are TSRs, it causes the NUL device to be held open.
7.	SHARE should be loaded on the file server. It will also need to be loaded on all workstations if there are different versions of MS-DOS running on the network. The recommended parameters for SHARE are:

SHARE /F:5120 /L:500
8.	Make sure you are running the most current version of FoxPro.
Additional Information
Additional information concerning Networking FoxPro for Windows can be found by looking at the following articles:

Q87690 | Q96346 | Q98996 | Q100434
Q89156 | Q97682 | Q99546 | Q101001
Q93327 | Q98684 | Q99918 | Q101290
Q95373 | Q98920 | Q99921 |

NETWORKS.DOC	12/13/93