>Hi!
>
>>To correct your statement, my test evaluates the elapsed times between data retrieval processes using ADO with an OLEDB provider and SPT that can only use an ODBC driver, in turn. The tests I've run with this code show that the ADO code runs slightly faster than its SPT counterpart on most rowsets.
>
>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?

>Let's add something like JCRS2DBF into your test and see result. I'm sure that SPT will be much faster (even with VFPCOM instead of JCRS2DBF).

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.

>
>>The comparison you mention was probably obtained using C++ code that used the OLEDB API directly.
>
>Yes, it's a COM server built in VC++ using ATL and OLEDB consumer templates. I think, it's not a bad idea to have something similar embedded into next release of VFP.
>

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.

>>Now you are saying you did a test using VFP and OLEDB directly, I'd like to see your code, because up until now I was under the impression that VFP could not use the OLEDB API directly, other than through ADO.
>
>It's my personal project and currently I have no enough free time to complete this work and place it on UT. But I'll send it in its current state on your email ASAP.

By all means do so, if there is a way I would certainly be interested in that.