Hi, Greg!
You wrote on Mon, 1 Dec 2003 20:22:13 -0800:
G> I have started to get this error since upgrading to VFP8.
G> Service pack 1 fixed some of the instances but a few still
G> remain, the error is:-
G> Index does not match the table. Delete the index file and
G> re-create the index (Error 114)
G> It usually occurs on buffered tables during tableupdate,
G> usually when the table is also opened in another work area
G> under a different alias. When i browse the tables at the
G> point of the error a record is missing from the table.
G> However, when i close the table and reopen it the record
G> appears. Re-creating the index does not help. I suspect
G> it is the temporay index that is being used is corrupted.
G> Does anybody know of a fix?
This error arise in the next scenario:
Session1 - table opened in shared mode and some record is RLOCKed. Buffering
doesn't matter
Session2 - the same table is opened in shared mode and buffering is set to 5
(table optimistic). SET REPROCESS is set to something non-auto, say to 1.
Not to 0 or -1 or -2.
We can modify the record that is rlocked in 1-st session, but upon
tableupdate we'll get error 109 - "Record is user by another" - that's OK.
Then if we'll try to modify this record in any way (even simple REPLACE
SomeField WITH SomeField) and try to commit this record SECOND time - we'll
get error 114...
In previous versions of VFP we don't get error 114 (every time we'll get
error 109), BUT index corruption will take place!!! Just try to modify key
(indexed) field, SET ORDER TO correcponding tag, made the abovementioned
actions with one addition : <change_field>-TABLEUPDATE-(skip 1 and skip -1
or pull record pointer in any other way)-<change_field>-TABLEUPDATE after
that you'll end with corrupter index (but not really corrupted CDX, but
rather corrupted in_memory view of index file) - say SCAN ALL + ? keyfield,
RECNO() + ENDSCAN - will show "duplication" of affected record like
1-2-2-3-4-..., or even - "cycling", i.e. some records will appear
infinitely, say 1-2-3-2-3-2-3-... depending on how you alter key field first
and second time.
So I'd say that now VFP behave more correct, generating error 114
How can one avoid this situation - you'll have:
a. Not to modify uncommited record in any way, between consecutive
tableupdates()
b. Make Tablerevert() if you'll get Tableupdate() error # 109 - it will
restore index file, so you can continue editing and saving attempts.
c. Combine variant b. with less or more complex wrapper - not to lose your
uncommited changes because of record being locked in the time of
tableupdate(). Something like this:
LOCAL oTempRec
SCATTER NAME oTempRec && FIELDS fldList created with the use of
GETFLDSTATE(-1)
* to include only modified records
TABLEREVERT()
GATHER NAME oTempRec && Or corresponding INSERT FROM or APPEND BLANK
* for newly added records
Note that <change_field>-<change_field>-...-<change_field>-TABLEUPDATE()
doesn't produce this situation.
--
WBR, Igor