>John,
>
>Jim's absolutely correct that any given table will, given a (I say mathematically) determined period of time, achieve a kind of "balance" where it will then move between a high and a low number of active records. I say mathematically because I'm convinced that if you take the factors that affect that table like number of records added each day, time duty cycle of any given record (ie. when does it become obsolete and moved to an archive?), and so forth you will absolutely achive stability and balance that can be mathematically derived. I have no clue as to what that formula might be *g* but I'm sure there is one. < g >

Sounds like your "business" is stagnant :) How about accounting for the hope that our imaginary business grows at good clip...then this "stable number" is not possible...we hire more employees, do more edits, etc...

>Having said that the question arises, "Should we ever PACK a table at all?" I say yes, absolutely. Consider this; if you do as Jim suggests (and as I would also) and you recycle those pesky deleted records by archiving the deleted ones (this one's for you Bruce! < g > ) first, then replacing the deleted record with the new one, at some point the table will become miserably fragmented. It's at that point I would suggest that a table is a prime candidate for PACKing. As to the best method for PACKing a table I'd refer to Pat Adams great advice that you copy the table (COPY TO) a new table FOR NOT DELETED() after you have set thr ORDER of the table to the optimally desired order for your records. Not only will you speed up retrievals but such things as BROWSEing the table will become zippier as well.
>
>After copying then rename the old file to a bacckup name, rename the new target (the one you copied to) file with the name of the old file and recreate the indicies. You'll also gain a little speed in that the index leaves will not be so jumbled internally.

Yes, this is what I'm referring to...a complete refreshing of the table, not just moving out the deleted ones.