Walter,

>Again, you don't show to understand the issue here.

I understand every bit as much as you claim to understand on the issue.

>If there are no or very little deleted records in the table, the DELETED() tag means overhead. Rushmore is going to process the index information while as a netto result it does nothing. You've wasted CPU/NETWORK/DISK IO. Even with the filtered SQL SELECT, If you're going to SCAN it, it will result in more network trafic and CPU resources used as with every skip it needs to process the index information again.

Ah, a qualification to your admonsihment. You may be forgetting that not everyone runs systems with "very little deleted records".

>Again when there are no deleted records, you win nothing.

If there are no deleted records there is no need to have SET DELETED ON.

>BOGUS. I'm not talking about how the product is working internally (hell I don't know either), but giving more information how it works logically would be nice. BTW, this information *IS* available for SQL server, so here goes your argument.

SQL != VFP. Since the internals of the way VFP works have not been released I'll stand by by argument in the context of this thread.

>Again, you don't see it. It is the concept that does not make much sense. You can do your tests and find it does do its job in your cases, but do not realize it crashes in others. If you understand the concept you'll see inmediately.

I see that a smaller binary index can be retrieved across the network ~ 18 times faster and that the time to reconsitute that into a rushmore bitmap could be done very fast. A byte in memory can be allocated and set several orders of magnitude faster than it can be retrieved across a network. The 18 number above is based on he relative sizes of a CDX for a 100k row table for a ag on deleted() with and without the binary attribute. 16384 bytes vs 307712 bytes.

You might want to take time to read the Europa help file for some of the information it does provide.

If you don't have adequate tests then you should create better tests. And base decisions on a weighted average.

>No, developers should understand why something is better than the other. Emperical tests are not giving you reliable information of an production environment.

Baloney. Empirical tests can and should be done in production environments (or in a dev environment that adequately approximates he prod environment) to make sure that an app is performing as well as it can.

>Knowledge and understanding is.

Knowledge and understanding applied in a particular context is more important.

For you to say "never" is just as bad as the old adage of "always". The best rule is to test, where it helps use it, where it hurts drop it. And reevaluate the rule with each release of the product because the rule will change over time.