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 >

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.

While the PACK command is foreign to the "big iron boys" it can impart some benefits.

Hope this helps a little.

Best,


>Hi Jim,
>
>So, in essence, this becomes an optimal solution for a table that has a lot of transient records? Like, for example, an open ledger period? Where you are neever going to get more than n records but the I/O will be high before the period is closed.
>
>
>>By recycling the deleted records the file will grow until it has that magic number of records, then it will no longer grow anymore. A defrag of the disk will put the file contiguous. The recycling of the deleted records will maintain the contiguous nature of the file and prevent further fragmentation from being introduced.