Hi!
>>You need to retrieve data from ADO recordset in order to make your tests more correct.
>
>If I change the line where the oCn.Execute is used to:
>

oRS.Open("Select * From inpart", oCn)

>ADO still executes about a second faster. What's your point?
>Now you lost me there. jcRS2DBF is an ADO rs to VFP cursor conversion utility, how would that be relevant here? We're talking data retrieval speeds.

OK, I'll try to explain my point better. IMO data retrieval speed isn't equal to time of rowset opening. You can open server-side cursor extremely fast, but this doesn't mean that you have got all data at this time.
SPT result already placed into VFP cursor, which is very fast in access. oRS.Open or oCn.Execute returns result in client-side (or server-side) cursor and its not the same as VFP cursor. You need additional time to retrieve data from ADO cursor comparing with VFP cursor. So it will be honest to have both results in VFP cursors.
If you don't like jcRS2DBF :), then you can loop through all records using ADO::MoveNext() and SCAN..ENDSCAN and compare results.

>At first I was going to reply that this comparison did not apply to VFP but left that aside because you mentioned three separate tests, one with the OLEDB API. But given the above I will say that simply put the comparison is not valid in the VFP context.

Why? The library mentioned uses FoxAPI and returns data from OLEDB provider directly into FoxPro cursor.