Lance,
I think this is something MS could/should fix. I will try to send this scenario to them.

If you SEEK(Expr, Alias, TagName) with a SET ORDER TO AnyTag, it's fast--even across the WAN. Again, my testing just assumes if there is much network traffic and the table(s) I'm using are accessed through the WAN connection, anything faster than 2 seconds means there was a minimum of packets. If any unusual traffic occurs, we quickly get minutes of elapsed time, not seconds. GO RecNum with SET ORDER TO SomeTag or without, SET DELTED ON/OFF, DelTag in place or not, makes no real difference. All is fast. I just tested GO TOP and GO BOTTOM with all options DELETED ON/OFF ORDERED, and found all of them to be fast. LOCATE with no condition was fast, unless the table has a DelTag and SET DELETED is ON--which makes sense.

The main point is LOCATE when an ORDER is SET reads the index file unnecessarily, and it apparently has for years. I guess the answer for now is--don't do that.
Charlie

>
>Another thing to consider is that this was all going on over a fairly heavily used network to begin with and the NT Workstation and even the server weren't running on particularly zippy hardware.
>
>I couldn't believe they found it acceptable and didn't call me. If I hand't gone on site I never would have found this problem. They would just start a query and go on break, so they actually were rather fond of my software. :)