>>The other case is where very few deletes occur, and it's next to impossible to determine what, if any, optimal table size. In this case, tables with production records come to mind. These tables are added to daily with very few, if any deletes occuring. There's little, if any, reason to try to "re-cycle" since the deletes are few and far between. Further, since all the reports are produced by queries, having to exclude deleted records would serve to slow the reporting process. However, because deletes can happen, I have to account for them, and thus use PACK.
>
Hi Jim,

>If any record may be deleted at any time you must account for them in the query anyway, so what is the difference if they stick wround as deleted until they are reused or you pack the table?

In my case (and I'm a corporate developer), users have been trained so that if they mark a record for deletion, they know to use the Pack option. They're also very careful about checking their work via one the summary reports (this is a "heads down" data input scenario). If they're off and can't find the reason, I'll hear about it. That's a rare occurance. In any event, the query does not check the delete status. Perhaps a bad design decision on my part, and most certainly one I'd have to think long and hard about in some other scenario.

>I already said the whole issue is moot with very small tables. However, very small tables have a terrible habit of becomming large tables later on.

If some of these tables become large I'd be very surprised (and in trouble < g >). Shaw's already a Fortune 500 company (NYSE - SHX), and the plant that I work from is one of four in Cartersville alone. It (the plant) is just a bitty thing of 3/4 million square feet. Currently, the largest of the "small" tables is about 53K. I think I'm safe for awhile< g >.