skip to main content
Part 3: The 32-Bit Drivers : The dBASE Driver : Connection Option Descriptions : Lock Compatibility
  
Lock Compatibility
Attribute
LockCompatibility (LCOMP)
Purpose
The locking scheme the driver uses when locking records.
Valid Values
Clipper | dBASE | Fox | Q+E | Q+EVirtual
*Clipper specifies Clipper-compatible locking.
*dBASE specifies Borland-compatible locking.
*Fox specifies FoxPro-compatible locking.
*Q+E specifies that locks be placed on the actual bytes occupied by the record. Only applications that use the dBASE driver can read and write to the database. Other applications are locked out of the table completely (they cannot even read other records). This locking is compatible with earlier versions of Q+E products.
*Q+EVirtual specifies that locks be placed on bytes beyond the physical end-of-file. Q+EVirtual is the same as Q+E except that other applications can open the table and read the data.
The advantage of using a Q+E locking scheme over dBASE locking is that, on Inserts and Updates, Q+E locks only individual index tags, while dBASE locks the entire index. The following values determine locking support as described:
If you are accessing a table with an application that uses the dBASE driver, your locking scheme does not have to match the Create Type. If you access a table with two applications, however, and only one uses the dBASE driver, set your locking scheme to match the other application. For example, you do not have to set this value to Fox to work with a FoxPro table. But if you are using a FoxPro application simultaneously with an application using the dBASE driver on the same set of tables, set this value to Fox to ensure that your data does not become corrupted.
Default
dBASE
GUI tab
Advanced tab[dBASE]
Advanced tab[FoxPro]