Craig,

>>>If an appropriate tag is not found, Rushmore may try to build one. In this case, the size of the table comes into play because it will take longer to index a large table.
>>
>>To my knowledge this is only the case in SQL SELECT statements (probably only where one or more joins are involved) and not in xBase statements.

>Nope. Rushmore doesn't care if it's a SQL SELECT or a LOCATE or a SCAN.

Therefore I doubt if this self creating index thing is a part of rushmore rahter than an specific SELECT SQL add-on performance tuner. I know the docs say something about the self creating index thing off SQL select, but I never have seen it mentioned in a direct relation to rushmore.

qote: 'FoxPro's SQL facility makes use of Rushmore as a basic tool in multi-table optimization, using Rushmore with existing indexes and even new ad-hoc indexes to speed queries'

note: the last word is '(SQL ?) queries' and not 'rushmore'.

This is the only documentation I could find to the subject. As I read it, it only applies to SQL select. When I try to understand the optmization process, this makes sense in a multi table query or queries that involve subqueries, but I can't imagine any situation that it can optimize a single table DML action.

Walter,