>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.

With the cursor location at client side for the connection object, both samples fetch all rows at that time, putting the test on the level with SPT. It is not the same as a VFP cursor of course, but as I wrote in my reply to Jim Nelson it depends on what your application needs are. For some applications it is not necessary to have a VFP cursor when you can access the data from the ADO recordset directly. With the exception of the report writer ADO data can be consumed from a recordset in VFP.

I'm not going to argue on looping the whole recordset, I know that a SCAN on a VFP cursor will be faster. Not by a whole lot if you use WITH.. ENDWITH on the ADO recordset, but then that is another subject altogether. Depending on the application I wouldn't use ADO if I needed to scan a large result set.

Regarding FoxAPI, you mean creating an FLL that exposes OLEDB functionality? That would be a nice utility to have. Now that would still be C or C++ code.. :)