Folks

Has anyone experienced a 'sticky record pointer' problem, where there is a delay between moving a record pointer in a master table and the movement of pointers in secondary tables controlled by SET RELATIONs during compute intensive updates. The effect is that I may not be on a valid record when replacing data and committing buffered updates.

I have been trying the proc below to 'shake' the pointers into being where they ought to be. I can't really say whether this does any good, because it's not on my PC that the app seems to have the problem.

Q1. Are CPU and RAM speed known issues with record pointer movements?
Q2. Does a DOEVENTS allow native VFP operations to 'catch up' with where they ought to be, or does this only effect threads in other apps and Windows itself?

John Burton

PROCEDURE AssertRelations
LOCAL nRecno
* sometimes weird errors occur with the record position
* assume 1 master table & 2 with relations set to the master
* 'ID' is some index tag in each of the tables
nRecno = RECNO("MasterTable")
GO TOP IN MasterTable
= SEEK(MasterTable.ID, "RelatedTable1", "ID")
= SEEK(MasterTable.ID, "RelatedTable2", "ID")
GO BOTTOM IN MasterTable
= SEEK(MasterTable.ID, "RelatedTable1", "ID")
= SEEK(MasterTable.ID, "RelatedTable2", "ID")
GO nRecno IN MasterTable
= SEEK(MasterTable.ID, "RelatedTable1", "ID")
= SEEK(MasterTable.ID, "RelatedTable2", "ID")
ENDPROC