>>>I have definitely determined that prior to the "wait window" Recno()=lnRecno (not 1), but after the
>>>"wait window" Recno()=1.
>>>
>>
>>
>>Bill, I bet that Barbara's suggestion is the internal source of the inconsistency you are seeing. VFP lets you relate more than one table into another table. Every time the record number changes in any parent table, the "related into" table will have its record pointer moved. I guess the way I look at the circumstance is "one work area, one current record pointer". When I have a lookup table (such as a dictionary of some type) that needs to be used/displayed by several different modules (asynchronously) within an app, I USE the table AGAIN in as many work areas as necessary to exclusively serve each module with its own record pointer into my dictionary. For example, when you have several browse windows open at the same time, each with a relation into the same lookup table, this is a way to keep a single record pointer from being whipsawed around in the child table. If you don't use an approach like this, you end up with incorrect data being displayed as you move from one
>>Browse window (or grid) to another. Sometimes using private data sessions will also address this problem, but not always (i.e., not if the same form sets more than one relation into the same table at the same time).
>
>Good points, Mark!
>
>Bill, I've heard of other problems which were 'solved' by adding a brief (and .001 is brief) wait window. However, I feel that you've simply bypassed a problem which may come back to haunt you.
>
>The reason this works may simply be that it slows down the record-number change just long enough for VFP to update its relations first instead of after the record change.
>
>Barbara

I agree with you that putting in a wait just creates a probable problem down the road which will be even harder
to solve then than now.

Please see my final solution in another thread.