PRB: Shared Table in DBC Remains Locked After Table Update

 Last reviewed: July 21, 1997
Article ID: Q171668
The information in this article applies to:
  • Microsoft Visual FoxPro for Windows, versions 5.0, 5.0a

SYMPTOMS

When using optimistic table buffering on a table inside a database container (DBC), a shared table remains locked after a table update that occurs within a transaction. This situation prevents other users from updating the table. The behavior occurs when the table is in a DBC, the table update is within a transaction and the buffer mode is optimistic table. The behavior does not happen when the table is free.

RESOLUTION

One resolution is to use free tables instead of tables within a database.

Another option is to check, within the transaction, whether the table is locked (ISFLOCKED() returns True) and if the table is locked, use the UNLOCK command to unlock the table.

A third resolution to perform a REPLACE on more than one record is to put the REPLACE statement within a loop so that the scope of the REPLACE statement affects only a single record.

STATUS

Microsoft is researching this problem and will post new information here in the Microsoft Knowledge Base as it becomes available.

MORE INFORMATION

NOTE: This problem occurs only when the scope of records affected by the REPLACE function is more than one.

Steps to Reproduce Behavior

The following code will demonstrate the behavior: 

   * Start of the Code
     CLEAR
     CLOSE DATABASES ALL
     SET MULTILOCKS ON
     SET SAFETY OFF
     SET TALK OFF

   * Create the database and table

   *********************************************************************
   * NOTE: If the table is not in a database the problem does not occur.
   *       The following line can be removed to verify this behavior.
   *********************************************************************
     CREATE DATABASE test

     CREATE TABLE test (CTest C(10) , NTest I)

     INSERT INTO Test VALUES ( "one", 1)
     INSERT INTO Test VALUES ( "two", 2)
     INSERT INTO Test VALUES ( "three", 3)
     INSERT INTO Test VALUES ( "four", 4)

     CLOSE DATABASES ALL

     USE Test SHARED
     =CURSORSETPROP( "buffering", 5) && Optimistic Table Buffering

     REPLACE NEXT 2 cTest WITH "test"

     BEGIN TRAN
        IF NOT TABLEUPDATE( 2, .F., "Test")
           ? "Failed."
        ELSE
           ? "Committed."
        ENDIF
     END TRAN

     IF ISFLOCKED( "Test")
      * UNLOCK in test && Uncomment this line to test the UNLOCK command
        ? "The table is still locked."
     ELSE
        ? "The table is not locked."
     ENDIF
     ?ISFLOCKED()
   * End of the Code

Keywords : FxprgMultiuser FxPrgTable vfoxwin
Version : WINDOWS:5.0,5.0a
Platform : WINDOWS
Issue type : kbprb

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: July 21, 1997
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.