>>>>FYI
>>>>
>>>>I have seen several postings over the last year and have personally had problems in multi-user environments ensuring that data (new or updated records) being posted at one workstation is available at other workstations. The information does eventually get seen by the other workstations. But in a real-time environment, more often than not, problems of this nature do arise.
>>>>
>>>>In the past I have tried using the FLUSH command at the data entry/update workstation, and the SET REFRESH command at the other workstations (and even closing and re-opening the tables) with no consistent results.
>>>>
>>>>The solution is to issue the FLOCK() command! I then am assured that I have all the current table information available to me. The actual code that I use is...
>>>>
>>>>DO WHILE NOT FLOCK()
>>>>ENDDO
>>>>UNLOCK
>>>>
>>>>This seems to bypass any buffering that the workstation or network has, and forces a read directly from the table.
>>>>
>>>>I hope that this helps to pull a multi-user thorn that has been in developers' sides (at least mine) for quite some time.
>>>>
>>>>//:^)
>>>
>>>what happens if i lock a record and go home for the day?
>>
>>You don't do that. The line after the loop unlocks the record.
>>
>>Joe
>
>but if i have a record locked and leave, your attempt will sit there until i return (or until the network admin throws me out)

That is what I thought you might mean...you, or another user, has a record locked at another workstation. Well, I would say that should not happen. You should not allow a user to do this. In other words, don't code so this can happen. I never let a user lock a record for more than a second or two. Of course, a counter could be used in the loop and every X number of attempts could bring-up a "Having difficulty locking the record. Abort?" message.

Joe