>>>>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().

Thanks for the advice. I have to go to my user's office to test before I know whether it is the culprit or not. I didn't set the reprocessing. I will do it in the testing also. 'DELETE FOR' is definitely a suspect but I am not sure if he is the cause or not because from what I heard, they have this message quite often (only two of them are testing). I can't imagine why DELETE FOR would take that long.

Also I forgot to mention one more thing. I am using PRIVATE DATA SESSION and modeless form for most of my forms. I think this may indirectly cause the problem but my guess is simply based on what I read about the danger of using PRIVATE DATA SESSION. I really regretted using it.

Any other opinion?