A.exe updates information in table TheData.DBF with a tableupdate(), THEN A.exe puts a message in table Notification.DBF with a tableupdate() for a separate process B.exe to read to know to work with the data put in TheData.DBF. Sometimes, in the above situation, the table Notification.DBF physically gets written to before TheData.DBF id written to, B.exe, sees the message in Notification.DBF and looks for the record in TheData.DBF but fails to find it because it hasn’t been written yet.

Microsoft says that this is not a bug. All they guarantee with the REFRESH setting is that the data will get written within the time set in the REFRESH setting. If one table gets written faster than another (Notification.DBF in our case) then the requested order can be different than the actual order.

Attempts at forcing a write … flush, commit, skip 0, go recno(), issued by A.exe against TheData.DBF have failed to solve the problem. Having B.exe delay seeking in TheData.DBF after it sees it’s notification in Notification.DBF would work, but as this problem seems to happen only once in several thousand times, I would prefer not slowing down the whole system to accommodate this.

Does anyone have another approach (or confirmation that this is the only answer).

Bob