>>>empty
>>
>>I don't understand the statement. If you're asking if the VFP OLEDB provider will use the index files on a VFP table to speed it's access, yes, but it produces recordsets, which do not have a clue about the backing datastore.
>
> To:Ed Rauh
>You are right,Rauh.
>How VFP OLEDB use the index file of the specified table?Can index file really speed up the application?Could u show me some brief example?Thanks

The OLEDB provider incorporates the Rushmore engine, so if you pose queries that match the functions used to create the indexes of the tables under reference, the indexes are used to resolve the query. However, once the query completes, the recordset is disjoint from the backing store - it is not aware of the index set of the table, although you can get it through execution of an SP, but it does no good for the rs itself; you have to order it within the ADO recordset, even if the backing store has indexes that match the ones that you work with. The problem is the disjoint nature of the ADO recordset; actions taken on the recordset do not immediately reflect in the backing store, and backing store resources do not 'bubble through' to the recordset behaviors. The idea is that you pose tight queries to limit the size of recordsets, or present the recordset in a natural order for your own manipulation. The recordset is not a direct equivalent of a native VFP cursor. The result of SPT (SQL PassThrough) is closer, but it also does not let you leverage the existing backing store indexes directly; you have to create your own on the views/cursors it brings over.