Michel,

I wonder if SET REFRESH *could* have some impact here???

I mean, *if* you have a default (or high) SET REFRESH while the user has a very LOW SET REFRESH, *possibly* (and this is relly stretching things here, since the Help states unequivocally that SET REFRESH is applicable only to BROWSE (but others have observed differently)) your system still "sees" the deleted record while in the other system it is not "visible".

Truly a wild guess, but as we all know. . .

good luck,
Jim N

>>Just a long shot.......
>>In an app I inherited, which doesn't use buffering either, the clerk gets an occasional update conflict message because she/he bangs to "Save" key too hard and causes a key bounce. Trapping the key strokes immediately before the save code is executed seems to have cured the problem.
>
>Here's more info.
>
>After having checked the error log, I found that the error from from the delete function of the framework. After having deleted the record, I am restoring the pointers to the original records for all the tables involved for the delete (parent and relational tables). In this case, I am only restoring the pointer for the parent table as there is no relation. So, in this case, after the delete was done, I am restoring the pointer to the deleted record.
>
>The error is occuring when I execute the GO lnOldRec, which represent the record the user wanted to delete which is in this case a deleted record as the delete command was ok.
>
>In this case, I may put a condition to avoid restoring the pointers. However, this doesn't explain why they always have the error while I can't simulate it.