Hi Charlie,

First, are *your* tests using FPx 2.6 being done on a machine where *NO* subsequent version of FP/VFP has ever been loaded? I sure hope that you answer yes to this one!

I was responsible for an app with several tables regularly hitting 2GIG (FPD 2.5, 2.6, 2.6a) and we were very sensitive to performance issues. Now it is true that our standard was always DELETED OFF. But we had never worried about that warning in FP's SQL/Rushmore regarding optimal when running with no TAG active because we never saw a smidge of difference either way. Also, we had assumed that it meant for *any* and all table(s) in a Select and it was too bothersome, especially given other words that SQL opened it's own anyways.

But I really am concerned that the rules seem to be changing yet it takes people stumbling on things to report varying observations. I really do not think that this is an acceptable situation!
For example, when Walter M. raised the issue of DELETED() tag not being helpful most of the time, most of us, and especially the acknowledged "guru"s were quick to ridicule him, some even continuing to disbelieve to this day!
Now I cannot say that I blame them for sticking to the "old rule" because it had proven true and accurate and most definitely helpful for a very long time. How and When and Why it changed is something we deserve to have been told about.

Think of the poor folks who have running apps at client sites and who only hear about trouble like this after a newer version is implemented! This is not the kind of stuff that necessarily gets detected in pre-implementation testing for a simple VFP fersion update.

I hope that you will share your results, and possibly your paper too, once completed.

Cheers,

Jim N

>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