>Shouldn't existing indexes be preserved exactly when a table is zapped?
Yes, but I wasn't sure how you had done this.
> My first guess was a change in collation ...
Should be preserved, too.
> ... since mismatches there tend to have dramatic effects (docs say Rushmore doesn't use indexes if their coll differs from the current one) but zapping doesn't change the collation AFAIK. Blocksize perhaps? ISTR that a table takes on the current setting for blocksize if you pack it.
IMHO, blocksize would have an effect on filesize, but not so much on performance.
This should be preserved, also!
>Also, NTFS reacts
very badly to fragmentation. Had a big performance problem today with some tables that were copied en block but ended up in the cracks between a million fragments created by TurboDB. Raw file reads from that drive were slower than reads from a 10 MBit network, and the defragger wailed that there was no free space that it could use (0%) even though it reported 53% free space on that drive. Defragged by reformatting and afterwards performance was back to normal levels. *g*
Difference in opinions hath cost many millions of lives: for instance, whether flesh be bread, or bread be flesh; whether whistling be a vice or a virtue; whether it be better to kiss a post, or throw it into the fire... (from Gulliver's Travels)
