Microsoft KB Archive/143284

= PRB: Error Generated Through Interface Clears READ EVENTS =

Article ID: 143284

Article Last Modified on 5/7/2003

-

APPLIES TO


 * Microsoft Visual FoxPro 3.0 Standard Edition
 * Microsoft Visual FoxPro 3.0b Standard Edition
 * Microsoft Visual FoxPro 5.0 Standard Edition
 * Microsoft Visual FoxPro 5.0a
 * Microsoft Visual FoxPro 6.0 Professional Edition
 * Microsoft Visual FoxPro 7.0 Professional Edition

-



This article was previously published under Q143284



SYMPTOMS
If an error is generated through the interface at a time when program execution is halted on a READ EVENTS, selecting Ignore from the dialog clears the READ EVENTS. Alternately, having an ON ERROR routine without a RETRY causes the same behavior.



CAUSE
If an error occurs, selecting Ignore moves program execution to the next line of code. If an ON ERROR routine is used, execution also resumes at the next line of code if no RETRY command is issued.



RESOLUTION
Conditionally execute a RETRY after testing for which line of code is active when the error occurs.



STATUS
This behavior is by design.



Steps to Reproduce Behavior and Resolution
This example uses the Customer table from the \VFP\samples\data\Testdata database. The READ EVENTS is placed in a procedure by itself. A RETRY is conditionally executed within the error handler when an error occurs and the program name passed to the error handler is the procedure containing the READ EVENTS.

  Create a new program containing the following code, and name it Readtest.prg. * Begin READTEST.PRG *

SET EXCLUSIVE OFF ON ERROR DO errhand WITH ; ERROR, MESSAGE, MESSAGE(1), PROGRAM, LINENO

* The following DO FORM allows the form to be cleared if the program * ends since the variable oReadTest loses scope

DO FORM ReadTest NAME oReadTest LINKED =Read_Events      && Call procedure to invoke READ EVENTS ON ERROR

PROCEDURE ErrHand PARAMETER nErrorNum, cErr_Msg, cErr_Msg1, cErr_Prog, nErr_Line

* Display error number WAIT WINDOW "Error # "+ALLTRIM(STR(nErrorNum))+ ; " In "+ALLTRIM(cErr_Prog) TIMEOUT 1

IF UPPER(cErr_Prog)='READ_EVENTS'  && Check for program/procedure *  RETRY           && Remove * to make error not clear READ EVENTS ENDIF

ENDPROC

PROCEDURE Read_Events READ EVENTS ENDPROC

* End READTEST.PRG  Create a new form. Add the Customer table to the Data Environment of the form. Then create a grid by dragging the Customer table from the Data Environment of the form. Set the ColumnCount of the grid to 5.  Place the following code in the Destroy event procedure code for the form: =TABLEREVERT(.T.)     && Do not save changes CLEAR EVENTS  Set the BufferMode of the form to 1 - Pessimistic.  Add a command button to the form, and place the following code in its Click event procedure code: THISFORM.Release </li> Change the Caption property of the command button to Close.</li> On the File menu, click Save, and save the form as Readtest.scx.</li> Run the Readtest.prg program. Make a change to the first record in the grid.</li> Start another instance of Visual FoxPro. Run the program in the new instance. Make a change to the first record in the grid. The WAIT window will be displayed with error number 109. The form will be released because the variable oReadTest is released (goes out of scope).</li> Go back to the first instance of Visual FoxPro, and close the form.</li> Edit Readtest.prg, and remove the * from the RETRY command in the ErrHand procedure.</li> Repeat steps 8 and 9. The form will not be exited in the second instance of Visual FoxPro. The RETRY causes program execution to remain on the READ EVENTS command.</li></ol>

Notes:


 * The READ EVENTS is placed alone in a separate procedure because this is the only way to reliably determine the line of code currently executing. MESSAGE(1) will not return the line of code within an .exe file or show whether the source code is present or accessible when the program is run.
 * The error that occurs is "Record is in use by another user." This is caused by the attempt to lock a record in the second instance which is already locked in the first instance due to the Pessimistic buffering scheme.

Additional query words: VFoxWin

Keywords: KB143284

-

[mailto:TECHNET@MICROSOFT.COM Send feedback to Microsoft]

© Microsoft Corporation. All rights reserved.