Doing a DELETE FOR... isn't a good practice in a multi-user environment. As Jim has suggested, at a minimum you should be trying to RLOCK each record before deleting it. If you don't, VFP will implicitly try to RLOCK the record, and you have no way of knowing whether or not it's successful.

It sounds like the process you are trying to do is best done when no other users are on the system, and you have exclusive use of the tables. Then you wouldn't have to check for RLOCKs on each record.

>I have a VFP7 application that moves data from one table to another (table1 to table2). It copies the data to a temporary table (table3) , then appends it to table 2. Finally it deletes the data from table1.
>
>The application is running in Windows 2000 or 2003 servers with multiple users.
>
>All tables are opened in SHARED mode.
>
>The specific commands employ "COPY TO table3 FOR ..." and "DELETE FROM table1 FOR... and finally open Table2 and append from table3.
>
>We have found that for some users in a random fashion it will not delete the data from Table1 thus producing duplicates in the data. In most cases (99.99% of the time) this works correctly. But in some rare instances this duplication is ocurring. Because it is so random, we can't find any common cause of this duplication (failure to delete from table1).
>
>One thing we have noticed is that if another user is browsing one of the tables involved, it may prevent other users from deleting data from the table. But this is not the central problem because the failure to delete ocurrs even when noone is browing.
>
>It is possible that user have corrupted indexes, so we use the COPY TO and DELETE FROM command with NOOPTIMISE to ignore the indexes. But it still seems to occur.
>
>Is there some problem with indexes and RUSHMORE technology in VFP7. I notice if I compile it in VFP8 and reindex, the index sizes are cut roughly in half. Is VFP8 more stable in handling these COPY TO or DELETE FROM commands?
>
>VFP9 doesn't seems to be releases as yet, but if anyone knows is VFP9 more stable in handling these issues.