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

>>Anyway, I wrote a program a while back that opened a table and did a completely Rushmore optimized search over a network. The table had about 10 million records in it. The code was using SET ORDER TO early on (for display) and then later called a fully Rushmore optimized SQL statement. This SQL statement took FOREVER (like an hour). I thought that was strange, and after some investigation found that it was searching the records sequentially and hauling all the data over the network.
>>Anyone know of where this might be documented, and why it's that way?
>
>I don't believe you <s>. I think something else is going on. A SQL opens the tables involved AGAIN, so it's not clear to me why it would be affected by the order. Having said that, I know that in general, there is a penality for having an order set, but I have always measured it as very slight, not the huge one you are experiencing. Could you test again with a simple test?
>

>LPARAMETER SetOrder
>IF m.SetOrder
>   SET ORDER TO Something IN MyAlias
>ELSE
>    SELECT MyAlias
>    SET ORDER TO
>ENDIF
>Timer = SECONDS()
>SELECT * WHERE Field = Expr INTO CURSOR Temp
>? IIF(m.SetOrder,"With an Order: ", "No order set: ")+ STR(SECONDS() - m.Timer, 8,4)
>