>>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
>
>This is exactly the purpose of Microsoft Message Queue (MSMQ). You can send the data to the queue and then B.EXE can read the queue and process the data.

Craig

You have sure got my attention, but what is MSMQ. I'll admit I've never heard of it until now. As a Visual Studio owner, do I already own it? Is it one of those free Microsoft products? Where do I buy it if I don't already have it? Is it just a concept that I should be building in VFP as a COM server?

There's so much to learn. I'm sure glad we've got the thread.

Bob