Hi Bernhart,

I too have found that 2091 is NOT "captured" by ON ERROR or TRY...CATCH when buffering is in effect.
However, checking the return value from TABLEUPDATE() will catch it - a .F. is returned and AERROR() will have details that you can action.

Personally, that it is not trapped by ON ERROR or TRY...CATCH seems problematic to me, but it seems I'm the only one who feels that way.

I remain keenly interested about the possibility of making a clean reproducible code snippet from this, because the present fix is more of a prevention than a fix.

good luck


>Hi Jim,
>
>Thank for your assitance.
>
>=FixRecCount("C:\cdbk70\amline\Data2\DatesParametres.DBF", .F. , .T. )
>This code change the header of datesparameters.dbf ( I verified).
>
>

>if lnActRecCnt<>lnRecCnt
>        WAIT WIND
>          lnHandle = FOPEN(pcFile,12) && Open file R/W, Unbuffered
>          FSEEK(lnHandle,4,0) && Record Count is bytes 4-7 in dbf header (0 offset)
>          FWRITE( lnHandle, Num2DWord(lnActRecCnt) )
>          FCLOSE(lnHandle)
>        endif
>

>
>But my table is not repaired.
>
>"Table OPEN time SET TABLEVALIDATE TO 1 or SET TABLEVALIDATE TO 3
>Assuming that the table header is lockable and a discrepancy of the record count versus the physical size is encountered, error number 2091 occurs immediately. Of course any active error routine will process for it.
>
>Note that a "Waiting for lock" message can be issued and that obtaining the lock on the header is mandatory for further processing to proceed.
>
>Data WRITE (INSERT or APPEND) time SET TABLEVALIDATE TO 2 (or 3, but error should occur on OPEN in that case)
>The data to be written is written, then the integrity check is performed. If a discrepancy is found then the operation is dependent on the buffering in effect.
>If there is no buffering in effect then error number 2091 occurs immediately.
>If there is buffering in effect then it seems that two possible outcomes are possible:
>- If there is no error processing in effect and the return from TABLEUPDATE() is not verified, then NO ERROR NOTIFICATION occurs!
>- If there is error processing in effect OR the FALSE return from TABLEUPDATE() is processed, then the error can be processed.
>In my testing neither ON ERROR nor TRY...CATCH...FINALLY intercept the error when any buffering is in effect."
>
>
>I am not enough qualified to regulate this problem.
>
>bernhart
>
>
>
>
>
>
>Hi Bernhart,
>>
>>The following might be helpful:
>>http://fox.wikis.com/wc.dll?Wiki~UDF_FixRecCount
>>
>>You seem to have a very reproducible problem here. I wonder if it can be 'compressed' into code suitable as "repro code" for a VFP Bug Report (that you could post here too)?
>>
>>The would be specifically GREAT **if** the situation does NOT involve TRANSACTIONs - MS has a repro for that but none for non-TRANSACTION processing.
>>
>>One other person who was persistently getting this error in a production application got relief when he moved his tables to a new HD. The guess there was that there may have been something a bit flaky in his original HD, which he knew to be an older one.
>>
>>As regards SDT, I don't know the answer.
>>
>>good luck
>>Jim
>>
>>>Hello Sergey,
>>>
>>>My setting for "SET TABLEVALIDATE " is 3.
>>>I tested 7 and 15 but I always have Meta.oSDTMgr.OpenAllTables(F., F., F.) always returns .T.
>>>and It does not detect the error 2091.
>>>Table "name" has become corrupted. The table will need to be repaired before using again. (Error 2091)
>>>
>>>Stonefield can it repair the error 2091 ?
>>>How to make to repair this table ?
>>>
>>>Bernhart