Just make simple test: create a table with 1 million records and USE it. If whole table should travel around, why it doesn't take time to open it in BROWse? Foxpro always finds the current entry point in the table (cursor) and brings surrounding packet of records. Therefore, if SQL-query return small subset by optimizable query, then Foxpro goes to appropriate index tag, finds table 'entry point' and does the same thing. Here lays the reason why it's important to run queries in right sequence, e.g. you want to join two 1 million records tables for some parameter which will actually limit recordset to 10 recs. In this situation it's better first to get 10 recs from first table and then run another SQL to expand recordset to another big table returning agail small number of records.

>Wow! I was way off base then. Just so I'm clear in my "new way of thinking": Are you saying that using "straight FoxPro" and accessing a table on a network drive, that the "whole table" doesn't come down the pipe? How's that? I guess I can see it if the table is indexed and you're doing some type query based on the index.
>
> Kevin "rock my world" Stroud
>
>
>
>Flame war? There is no such thing here:).
>However, you are really get some misunderstanding. Foxpro never claims whole table to local machine (surely, if you have Rushmore-optimizable SQL expressions), and only retrieved recordset will travel over network.
>
>>Maybe I'm misunderstanding here (not trying to start a flame war! <grin>):
>>
>>I think that if you have a huge table/database and you're actually wanting a result set that's fairly small, then SQL Server would be the best approach since the entire table doesn't have to come down the network wire and be operated on by your local machine (the operation can be performed on the Server, which you've "beefed up" in memory, processor, etc. just for that kind of operation).
>>
>>If you're querying a fairly small table, then using VFP alone will be faster because your machine can perform the operation directly (yeah Rushmore!) and you won't have the overhead of establishing the SQL connection and all of that handshaking.
>>
>>If I'm wrong - let me know!
>>
>> Kevin
>>
>>
>>I have to disagree with you here. VFP will be always faster than SQL-server on light traffic (doesn't matter how big your vehicle-recordset is) and slows down on busy traffic with many cars (users changing data).
>>Once again, hundreds of thousands of records is not a limitation.
>>
>>>Kevin,
>>>
>>> How big are your inventory files? If it's a few thousand records, SQL Server *is* probably overkill; if you're doing queries on hundreds of thousands of records (and returning result sets of, say, a few hundred records) then it's probably your best approach.
>>>
>>> Kevin E. Stroud
>>>
>>>
>>>
>>>Right now we have some VB apps that use SQL 6.5 on the back end. We have about 20 active users. most of them doing simple inquires into inventory available for instance. I dont believe we have a busy system. The software seller tells me that SQL 6.5 is overkill.