>>I've seen this before...but a question comes up: I have a lot of user selected orders. So does this mean it's worth storing the current tag to a variable, doing SET ORDER TO, and then restoring the order after the query?
>
>Bruce, I'd run a few checks. It would depend on the # of queries you're doing, the size of the tables, etc. You have to keep in mind the added processing time for the 3 actions you mentioned, too.

I guess some benchmarking would be needed...

>Where I'm most conscious of it is when I load tables that will be used in SQL queries ONLY in a form, not in displays. I always try to load them without an order specified

I have an app that does queries on a 300 meg table. It's legacy 2.x coding, but it sets the order before every query to the left side of the WHERE clause and runs magically fast...But perhaps with no order set it will be even faster since the coded order may be redundant?

I guess the question here is does SQL always ignore a coded order and do its own index search?