I meant something like

select count(*) from (calias) where cTAG=tcKey and deleted() into array laDel
if laDel[1]>0
*** uncertain how your code best fixed to assumptions
endif
IF !SEEK(tcKey,cALias,cTAG)
 INSERT INTO ...
ELSE
 REPLACE ...
ENDIF

or

lcdele = set("DELETED")
set dele off 
IF !SEEK(tcKey,cALias,cTAG)
 INSERT INTO ...
ELSE
 REPLACE ...
ENDIF
if lcdele=="ON"
 set dele on
endif

as a table never is safe from others fiddling with it.


>>Back when vfp was enhanced, my idea for an additional parameter for indexseek to ignore set deleted filtering was not wanted - which was meant for such situations. Still, your code for replace/insert ***should*** take care of that: either set deleted off for the check and reset or add another check with for deleted(). That way THAT error would never occur, no idea of the coworkers addition would have created other problems in the system
>
>That's the sole place that uses such stuff. Any other primary will run on synthetic, incremented numbers, so it's very hard to insert a conflict.
>
>The code would have not failed on developers machine because the carbage collection was packing fast enough. Normaly this kind of job is done by a supervisor outside of general business - by the way the supervisor is doing his job - so no hickup on this for more then 10 years. There must have been something - the index should be changed to something random - but it's never updated by that code.