PC Toledo

Alternative Exclusive Use Locking

There is a known problem with Paradox 7 table and record locks not functioning in this environment. More specifically, if a Paradox user is working from a Windows NT machine their table/record locks are not seen by any other user, and vice versa. This impacts any Keep In Touch function that requires exclusive use table or record locking, such as running Imports, FEC/State Filings, or even during multi-user data entry (i.e. where two users may be attempting to edit the same record). Moreover, when run from an NT Server, Paradox does not properly “clean up after itself” upon exit. That is, lock files (*.lck) are often left in the :db: directory. The solution to this problem is to set the “NT Lock Alternative” setting in Keep In Touch. This setting can be found by going to the Maintenance tab, Configuration Module, and clicking on the System category. In the right side of the window will be the “NT Lock Alternative” setting. Double-click this and set it to “Yes” if there are any Windows NT systems in your network environment. Note that this setting does not work if any Windows 2000/XP machines are involved in the network. It is important that you do not change this setting to “Yes “ if Windows 2000/XP machines are present.



Disable Opportunistic Locking

In an attempt to optimize speed, Windows NT, Windows 2000, and Windows XP employ aggressive file caching, which can wreak havoc on a multi-user relational database. Turning off Opportunistic Locking on these operating systems has been found to have a dramatic effect on decreasing the incidence of data corruption. The following excerpt comes from Microsoft’s KnowledgeBase (Article ID: Q126026):



“The Server service now caches the file handles (RFCBs) associated with files it has opened on behalf of a client request. Although write requests proceed normally, close requests are acknowledged by the server, but are buffered from the file system. This is intended to optimize response time to repeated open/close operations performed by clients. In regards to Opportunistic Locking (oplock), this optimization is a logical extension of the way a client caches its own file close request and relies on the server to arbitrate future requests for file access by other clients. In rare situations, Oplock must be disabled for compatibility purposes. RFCB caching also includes a configurable parameter in the registry to modify the server's behavior.”



(For additional information on Opportunistic Locking, see Microsoft TechNet - February 1998, PSS ID Number : Q150991) (http://support.microsoft.com/support/)