>>>>I have been tormented by this message for months. When two or more users start to use my invoice form, I get this error. I am on optimistic buffering mode (master - record buffering, detail - table buffering in grid). It happens occasionally when a user finishes one invoice (tableupdated) and is half way through the second invoice entry while another user is doing the same stuff.
>>>>
>>>>Anyone can suggest the possible cause of this problem?
>>>
>>>How do you add records to the table? How do you assign primary keys? Does your code contain any REPLACE FOR or REPLACE ALL statements?
>>
>>I use TASTRADE kind of NEWID to assign primary key (surrogated key). After APPEND BLANK in the master table, I use INSERT (key) VALUES (key) where key is the value obtained from master table. In grid, I use REPLACE key WITH master.key. I can't find any REPLACE ALL/FOR command in my form but I certainly have DELETE FOR EMPTY(xxxfield) (details table) before I do tableupdate. Do you think it matters?
>
>YES. DELETE FOR and REPLACE FOR lock the header and do not allow for updates while they are operating. What is your reprocess setting? If you set it to automatic or some safe high value, you can get by this by having your update wait for the header to free up before giving up. Remember that the reprocess setting is scoped to the current datasession, so the best place to set it is either in the DE beforeopentables.
>You should also think about if the best place for your DELETE FOR statement is right before the tableupdate(). If it is, make the changes stated above and definitely create an index on EMPTY(xxxfield) (or whatever the complete FOR clause contains). This wlil minimize the time that it takes to perform the DELETE FOR statement, and thus the risk of a collision during your TABLEUPDATE().

I went down to my user's office to test and the error is gone after I SET REPROCESS TO AUTOMATIC in LOAD method (mine is private data session). Thank you very much for your advice.

However I have another problem. A problem that is more serious. If you don't mind, can you take a look at my article on 'RECORD IN ONE STATION ...'?

Once again, thank you very much. Your advice probably saves me a few days work.