>Cetin,
>
>SNIP
>>I expect seek be fastest here (I would do 'set near on' and seek 1700002, 1700001 might not be there).
>>OTOH removing 'nofilter' on SQLs I expect them to be much faster than 30 secs too.
>>VFP SQL unlike SQL server's is not kind enough to break when it finds top n :( If this wasn't a PK issue it would count too.
>>Cetin
>
>Why would you think that rmoving NOFILTER would make it dramatically faster?
>
>Also, are you saying that you believe that TOP n works substantially differently between SQL Server and VFP SQL? This would seem odd to me.
>
>Jim Nelson
Jim,
If you remove nofilter then it could work as a filter on table. Forcing to create a true cursor would slow it down IMHO (more disk operations to create a new cursor).
I don't just believe :) It's that way. VFP SQL is kind of hybrid that's missing many specifications of ANSI SQL92 (I don't mean I know that specifications well but as I go deeper in SQL server and it says 'this is ANSI SQL 92 specification' - I see that VFP is lacking of it).
Say you have 3 names such as 'AAAA'. VFP SQL would return all 3 when you say just top 1. OTOH SQL server stops when it finds the 1st (unless @@rowcount setting forces other way around). This is not the only point VFP SQL is different, it's very different an much less capable:(
Cetin