>George and Larry
>
>Unfortunately, this goes right back to the initial topic. If there are 2 ways to do something (in this case move to the first record in a set), we need a way to know which is the best way (and when to apply it). LOCATE works faster than GO TOP only when a filter is in effect. Your sample code only proved that GO TOP is faster when no filter is in effect. Your comparisons didn't encompass the entire situation.

I acknowledged this elsewheres in this thread. BTW, doesn't the speed difference decrease if the filter in effect is non-optimizal?

>Now its also true that we should be using views. I wrote another article that proved using Rushmore optimization at all in a remote view scenario is overkill. We really should test and proclaim loudly that SET OPTIMIZE should be OFF where remote views are used.

Well, since I'm working on moving to SQL Server 7.0, I appreciate this tidbit of information.< s >

>Al,
>Your statement that the help shows LOCATE cannot be used without the FOR clause is right. The help is wrong. George's code proves that. The real issue is that a client will be happier with a snappier program than with a sluggish one. The snappier program will only come from using the snappiest code. Its our duty to make the best fastest prettiest applications we can deliver on time and under budget.

I hope you don't mind me jumping in here, Mike, but I don't entirely agree. It's not that I disagree with the premise that clients will be happier with programs that perform quickly and efficiently, I don't. What I disagree with is that it is always necessary to use the fastest means available.

For example, everyone knows that FOR...ENDFOR is faster than DO WHILE...ENDDO, right? However, in most circumstances (Bruce Campbell and I had an exchange on this some time back and, if I recall correctly, you have to get up into the 10s of thousands of iterations before a difference of as much as 1/10 of a second is realized), it doesn't make the slightest bit of difference to the user. The same holds true with using an in-line IF statement rather than IF...ELSE...ENDIF.

The problem here is that using a construct simply because it's "faster" without any regard for the context can lead to code that is more difficult to read and thus maintain. This cannot only lead to problems for the developer, but, in some cases, the end user as well.

This is not to say that I believe that these things shouldn't be ever be done, but only that a quantifiable reason for them to be done should exist.