Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Baffling Delete Problem
Message
De
19/08/1997 20:44:58
 
 
À
19/08/1997 18:58:57
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Divers
Thread ID:
00045076
Message ID:
00045717
Vues:
47
You're right that the PACK *WOULD* have fit in the space freed up by those 25000 records. But, this is impossible, because each time you make a PACK, VFP *COPIES* all not-deleted records to a temporary file, deletes the original dbf and renames the tmp file to the original name of the dbf. BTW, it does these things ONLY if it has enough space to write the tmp file. If not, the PACK will fail with an "There is not enough disk space for x:\...\...tmp" error.

So, PACK will NEVER write in the same disk space as the original dbf. So, you *cannot* make any assumptions on where the new file will be written.

All you can do it's to calculate the maximum number of clusters that will be taken by the new file, so, the maximum number of fragments and, in this way, you can appreciate if the fragmentation *could* have been the problem.

BTW, since the disk fragmentation is unrepeatable, further tests may not be conclusive.

HTH,
Vlad

>The fragmentation theory might be *IT*, but it looks to me that, once you did the DELETE of 25000 records, the PACK would have "fit" in the space freed up by thos 25000 records. In other words, the re-PACKed file would be in (roughly) the same space as the original. I could see fragmentation causing serious delays if individual tracks were widely fragmented, but your sequence of events suggests that this is not the case.
>
>An interesting phenomenon for sure! And one that might be REAL enlightening to get to the bottom of!
>
>Cheers
>Jim N
>
> >>>>Hi all,
>>>>>
>>>>>Today I deleted 25,000 records from a 30,000 record table, and packed it. A SQL (40 records) which had been taking >>:-(((
>>>>>So, I:
>>>>>
>>>>>a. reindexed. Still slow
>>>>>
>>>>>b. re-packed Still slow
>>>>>
>>>>>c. checked every clause in the SQL and matched them with indexes. Still slow
>>>>>
>>>>>d. Restored the original. Speed was fine. :-))
>>>>>
>>>>>e. Deleted, speed was fine. :-)
>>>>>
>>>>>f. Packed - slow again :-((
>>>>>
>>>>>g. Copied data (5K records) to a temp file, ZAPped and appended.
>>>>>
>>>>>Speed is now terrific - almost too fast to see. :-)
>>>>>
>>>>>Question: Why did this happen?
>>>>>
>>>>>TIA
>>>>>Barbara
>>>>
>>>>Try and delete the index, then re-create it again.
>>>>
>>>>Dave
>>>
>>>Deleting and recreating the index is like , as my wife would say, taking a water pill at that time of the month....gets rid of the bloat.
>>
>>Matt & Dave: I did the delete/recreate as well as a simple reindex. Didn't help. I COULD replicate it the whole matter, as you saw from my restoring the original data. I have a feeling that Vlad Tatavu's suggestion about disk fragmentation was correct. If I ever have time, maybe I'll try a restore, delete, pack, defrag trial to see if it works.
>>
>>Thanks a lot for the suggestions.
>>Barbara
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform