>>...With DBFs you only have to read 10 records across the network, then you can display the browse.
James.. are you absolutely sure about this.... ?
Remember that DBF's are read completely from disk, so if you have a browse , you will have to read ALL the 10.000's records together with ALL its fields, and also all the supporting DBF's related with the main one.
With SQL .. only the fields you want to show, then you can LOAD whatever you want... so NET traffic is reduced dramatically....
Yes, I am positive. With DBFs you only ever have one record in memory at a time. With a browse you read each record then display it and continue until all the visible records are displayed.
The only time you would ever read all records is if you were doing some kind of processing of all records (like finding a total, maybe), but still only one record is in memory at any time.
With SQL you work with recordsets which as you know are basically arrays. They may contain one or more records. If you do a SELECT *... then you ARE going to read all the records into memory (into the recordset) at one time. If you then browse the recordset you are displaying records from the recordset instead of reading them from disk like when you using a DBF. The browse display will be very slightly faster with a recordset but probably not detectable by the user.
Note that using scopes you could create an array from a DBF and use it just like a recordset. Using scopes you are only reading the records that are within the scope. So, this would probably be very similar in performance to SQL.
SQL will have an advantage when you are selecting records that you do not have an index for, thus you cannot use scopes. In this case the server reads all the records an only sends those within the parameters of the SELECT statement. When using a DBF you would have to read all the records across the network (but you would still only have one record in memory at a time).
In the sample I do...
select rut,nombre,field1,field2,field3 from clientes
and "clientes" TABLE has 35 FIELDS, when I dobleclick the record, I do a new RECORDSET containing all the methods of the Complete recordset, but only the present record (with all its fields) to edit, append, delete... etc etc
SQL does have the advantage of reading only select fields. You cannot do this with DBFs.
Regarding TADOBASE...
I have implemented Paging with that, no matter if the DB has it or not. I read ::nPageSize records each time, and if you see the Methods, I can control when each "miniRecordset" ends to load another...
I still do not understand exactly how you are doing this. Do you load a new miniRecordset with each keystroke of an incremental search (which contains just enough records to fill the browse)?
AS I STATED...
I CAN do incremetal searching with ADO and SQL, the TEST shows it.
I think is agreed that it can be done, but the question was, can it be done without reading all the records in the table into a recordset?