The query is not RUSHMORE optimizable. It does require a table scan in both cases.

>My ODBC connection to a FoxPro table is horrifically slow. This all started when I was trying to import some data into SQL Server using ODBC. I just needed to grab a single value, and the query took long enough that I couldn't believe it was actually using the indexes.
>
>Within FoxPro, this query will always work in under a second, since I have an index on the "inst_id" column (which is an integer field).
>
>Select max(inst_id) from results
>
>I duplicated the problem within Excel (using the "New Database Query" to try this same sort of query over ODBC). Same sort of slowness: 15-20 seconds long.
>
>Finally, I decided to do it within FoxPro but with the convoluted method of using ODBC with a SQLSTRINGCONNECT statement. Sure enough, my query through SQLEXEC was just as slow. Timing it, I found it averaged between 20 and 70 seconds.
>
>This seems like a full table scan to me. I've played around with enabled/disabling the "Fetch Data in Background". Likewise, turned on and off the Exclusive, Deleted, and Null options. Nothing seems to make a difference. Tried it against the table when it was in a DBC, and then tried it as a free table. Still the same. It seems as though any query through ODBC simply WILL NOT use my index. Has anyone seen similar performance? I've searched these threads pretty well and have only seen some vague guesses as to whether ODBC can use indexes.