PRB: Valid Routine Results in "Record Not Locked" Error

Last reviewed: June 27, 1995
Article ID: Q111919

The information in this article applies to:

Microsoft FoxPro for Windows, versions 2.5, 2.5a, and 2.5b
Microsoft FoxPro for MS-DOS, versions 2.0, 2.5, 2.5a, and 2.5b
Microsoft FoxPro for Macintosh, versions 2.5b

SYMPTOMS

A VALID clause on a GET field or BROWSE field accidentally releases an automatic record lock, causing a "Record Not Locked" error message when the valid routine returns .F. The error will not occur if the valid routine returns .T.

CAUSE

The following sequence of events will cause the automatic record lock to be released:

The record lock is placed automatically through a command, such as READ or BROWSE.
During the VALID routine, the record pointer is moved to a new record.
Another command, such as REPLACE, that places an automatic record lock is executed on the new record position. Since only one automatic record lock can be effective at a time, the original lock is released when the new lock is placed.
The VALID routine returns a .F. value. Control returns to the original GET field or BROWSE field, causing the record pointer to be moved back to the original record. The automatic record lock has been released, which causes the error to occur when editing control is returned to the field.

RESOLUTION

There are two possible resolutions:

When the record pointer is moved to a new record, lock the record by using the RLOCK() function. Make sure that the SET MULTILOCKS ON command is in effect. While this will prevent the problem, the lock must be released programmatically when the pointer is moved to a new record. This constant locking and unlocking can slow down system performance.

-or-

After the second automatic record locking command is issued in the VALID clause, move the record pointer back to the original record and issue an RLOCK() function. For example, in the LOSELOCK program used to reproduce the problem (see "More Information" below), the changes will appear as follows:

      m.cno = cno
      m.recno = RECNO()
      SEEK m.cno
      IF FOUND()
         WAIT WINDOW "Record exists"
         REPLACE cno WITH m.cno
      *************************************************************
      * The following 2 lines eliminate the error
      *************************************************************
         GO m.recno
         =RLOCK()
      *************************************************************
         RETURN .F.
      ENDIF

MORE INFORMATION

Steps to Reproduce Problem

Create a TEST database by issuing the following commands in the Command window:

      USE tutorial/customer
      COPY TO test NEXT 10
      USE test
      INDEX ON cno TAG cno
      SET ORDER TO TAG cno

Create a program file named LOSELOCK with the following commands:

      m.cno = cno
      m.recno = RECNO()
      SEEK m.cno
      IF FOUND()
         WAIT WINDOW "Record exists"
         REPLACE cno WITH m.cno
         RETURN .F.
      ENDIF

In the Command window, issue the following command:

      BROWSE FIELDS cno :V=loselock(), company, contact

Use the DOWN ARROW key to move to the third record.
In the CNO field, type the same customer number that appears in the first record. A "record not locked" error should occur.

Additional reference words: FoxMac FoxDos FoxWin 2.50 2.50a 2.50b errmsg
err msg
KBCategory: kbprg kberrmsg kbprb
KBSubcategory: FxprgBrowse

THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: June 27, 1995
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.