Dragan,

>It's only the rule that TOD (tag on deleted()) will always speed it up that's demythologized. It helps in only 98% of the cases, or so - but the 2% seem to be recently discovered (after the article, and couple of months of discussion here on UT). The cases which fall into the 2% seem to be those when a table already has many tags, the result set is relatively large, the table is large, and the tags involved take a large chunk of memory to process. Then, using up extra memory to check the TOD seems to add overhead - this memory may better be used to speed up other processing, make bigger buffers for other tags etc.

Well in 2% the TOD is slower, in about 96 % it makes no difference, and only in 2% it makes a significant difference in terms of optimizing. When generally it makes no difference, It degrades performance in inserting and deleting record. Besides that Indexes that don't exists, don't get corrupted.

>As we actually know very little of Rushmore's intestines, I don't see why would my SWAG be smarter than yours :). Still, considering Christof's message in this thread, it seems to be that having no TOD on a large table with many indexes and a small result set may be faster than loading the TOD; in many other cases TOD serves good - VFP doesn't have to parse the result set to check for deleted records then. It seems to be we only got one "firm rule" converted to the more common "it depends".

Well, this is only the case *IF* the table contains considerable amounts of deleted record. I'm sure the most tables don't...

Walter,