Walter,

That's interesting because AccPac Pro Series has deleted() indexes on practically every table. Could it be because many installations never pack out tables for months and months on end?

I'm definitely not disagreeing with your advice, I just want to think about it before ripping all the Deleted() indexes out of Pro Series.

Greg

>Hi martin,
>
>>Just wanted to point out that my own experience showed me that it is not plain record count what slow things down, but having too many deleted records. The delay at USEing the table can be prevented with proper indexes on deleted(), as it is caused basically because a scan is needed to find the first non-deleted record.
>
>A very, VERY dangerous advice. an INDEX ON DELETED() will cause you headaches on large tables since for every rushmore optimizable expression about the whole index tag needs to travel the network before even finding one record. A simple browse statement can take several seconds to execute esspecially on slower networks.
>
>A simple USE could take several seconds as well (though I could not quickly replicate this behaviour in VFP8). It is way better to ensure that no deleted records exists at the top of your table (depending on the index order you set initially with the use command).
>
>An index on deleted() almost never is a good idea. This is a proven fact and there even is an article in Advisor handling this specific problem. So please, please remember: Throw away your indexes on deleted()...
>
>Walter,