Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Problems copying data to new table, deleting from old
Message
From
10/01/2005 14:57:49
 
General information
Forum:
Visual FoxPro
Category:
Databases,Tables, Views, Indexing and SQL syntax
Miscellaneous
Thread ID:
00975745
Message ID:
00975765
Views:
16
>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.


Richard,

Not sure if this would help, but have you tried doing a RLOCK on the table you are moving the data from?

Also, why are you moving the data to a temp dbf. It would be faster to just do an INSERT INTO the destination table with the values from the source table.

HTH,
Jim
Previous
Reply
Map
View

Click here to load this message in the networking platform