Barbara,

I *think* more trials might well be in order here.

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