>>This does bring up a question, however. How can a LOCATE without an expression be optimizable? If there's no expression to optimize...
>
>from what little i know of optimization, i thought that some kind of index is cached. The reason NOOPTIMIZE has always been available is because some operations could cause the cache to become obsolete. My guess is that Locate is using this cache (even without an expression) while GO doesn't benefit from it.
>
>Does this sound right? I admit rushmore optimization is beyond my comprehension, and it's only by luck that i've had any success with it.

Hi Michael,

I'm not sure. One would assume that an expression would have to exist in order for optimization to occur in the first place. There would have to be something to be compared to (the FOR clause versus existing index expressions, for example). However, here, no FOR clause exists, so how is any legitimate comparison made?

I would say this: Despite the fact that a simple LOCATE may be faster than GO TOP, I would be highly reluctant to use it. Why? To me this falls into the category of an undocumented feature. I could not, in all good conscience, recommend to anyone that they use an undocumented feature. To me, this falls into the category of a programming "trick". I avoid "tricks" like the plague, since there's no guarantee that they'll work from one version to the next.

Let's assume, for a moment, that the following occurs. The Fox team modifies the way GO TOP works so that, with a filter in place, it becomes faster than the LOCATE. Now in conjunction with that, they also fix the compiler and/or run time library so that either a compile time or a run time error occurs. What happens then? I've got a lot of additional work to do in locating and replacing every instance where I've used it. If they only fix the run time library, all of a sudden I'll have a bunch of upset users. Thanks, but no thanks.

Bottom line, IMHO, don't rely on undocumented features.