Hi Richard,

in this case, I suggest you add a logical field Moving, and then set this field to .T. for all the records you must move.

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