Jim,
I'm writing an article for our Midwest FoxPro Users Group concerning the DELETED tag and other Rushmore thoughts. The reason I replied to the Lance's message here is that my understanding does not account for his assertions, and I hope to get a more complete description of his environment to adjust my ideas....or his, whichever it is.
BTW, I have not been able to recreate any significant example when a DelTag is helpful. I am testing with DOS 2.6 and VFP 6.0 SP3, with local tables, over a 100Mb network, and over a WAN. (I happen to have the same group of 100,000-250,00 record tables with quite a few deletions in a lot of places.) I don't have a network sniffer, but over the WAN, one can get a good idea of the difference in network traffic.
So far I see no evidence of any decline in Rushmore performance. I believe its just a case of more folks doing more work with larger tables. Several years ago George Goley was proposing doing SQL with SET DELETED OFF 'cause it was must faster. He didn't say why, but I think now we know. With a tag on DELETED(), all the table's NOT DELETED() pointers were transmitted to VFP--not the records, just the pointers, and that creates a lot of traffic.
If you, or any lurkers have a scenario where a DelTag is good for a SELECT, (and I don't mean where you are selecting only the deleted records), please let me know of your circumstance.

>Hi Charlie,
>
>I tend to concur with your feeling that the performance penalty of leaving an order set is (or at least has been) very slight. And considering JimB's reply I would say, despite Jim's conclusion to the contrary, that the ordering should have effect only on the result set (and even there, only in some marginal way since SQL seems to need an ORDER BY to ensure sequenced output).
>
>On the other hand, there may have been some change inside VFP as to how these things now process compared to previous editions. Alternatively, maybe there is something about more apps being tried/run over slower dial-up lines/modems. Lance doesn't say that his was such a case, but it may be.
>
>The FPA article of a few months back exposed problems with both an 'ill-chosen' index on DELETED() and VFP's processing of the "NoDataOnLoad" property. This *was* observed because of using slow dial-up line(s). That article went to some length to confirm that the same "problem" existed in FPD/FPW 2.x (the DELETED() part that is). However, since much of what is installed by a FP/VFP installation is mysterious and goes to common Windows directories, I found myself wondering about the absolute "cleanliness" of their test confirming similar processing in FPx. What if the SQL processing involved is actually in common (used by *any* version of FP/VFP) DLLs? This would taint any observations.
>
>What I do feel is that it seems somewhat strange that we are suddenly getting more and more reports of anomolies in VFP's SQL processing that didn't seem to come up until now.
>With the MS push to have VFP used as the mid-tier of future 'solutions', which I see as the demise of the usage of our beloved super-fast data access mechanism (the VFP "engine") in favour of (any) other mechanism (like MS' powerful but expensive SQL Server), MS may have some incentive to make the VFP SQL facility less fast. I suppose that it is also possible that they are simply making changes to the "engine" without thorough testing. The fact that VFP 6 was published with a major performance problem regarding something so simple as many screen objects leads one to question this possibility too.
>
>Whatever the real situation is, it would be real nice if MS and the VFP team made some effort to tell us a few more details. I wouldn't expect them to inform us of 'deliberate' slow-down additions, but I would expect to hear more details behind the factors that can affect performance. A simple statement like 'Note For optimal performance, don’t set the order of the table' really isn't enough any more, given Lance's report.
>
>Regards,
>
>Jim N