Hi!
"OLEDB" != "ADO", so let's talk about three different things: ODBC, ADO and OLEDB. Actually, your test show that ADO faster than ODBC. ODBC retrieves data row by row, while OLEDB (and ADO) retrieves the whole rowset, and it may be more effective for large datasets. However in general ODBC faster than ADO. I've seen in MS newsgroup a comparison diagram, which shows that in case of MDAC2.6-2.7 OLEDB slightly faster than ODBC and two times faster than ADO. My tests in VFP shows the same result. For example, opening "Titles" table in Biblio.mdb took about 0.8 sec using ODBC and 1.5 sec using ADO (and 0.6 sec using OLEDB).

>>What I meant is that the technology behind OLEDB is slower than ODBC. To justify what I said, OLEDB is a set of COM servers, while ODBC is a C-based API. ODBC is more direct, while OLEDB is more indirect. However, OLEDB is more flexible than ODBC.
>>
>>You said you wrote a VFP program to access SQL data using an OLEDB provider. That means you're using ADO, which wraps a COM object model around the OLEDB provider which is also a COM object. I can't imagine that would be faster than accessing that same data using ODBC directly from a VFP view or SPT statement. Is that what you're saying, that it is indeed faster? Obviously, this will be news to me.
>I can see your point about COM versus C-based DLL but still my tests have shown that OLEDB is slightly faster in retrieving data. The following code is a simple test that I ran some months ago:
>Now I wouldn't say this is the definitive way to tell which one is faster, but it should give you an idea of the data retrieval times. I tested with several tables of varying sizes and only on small tables was SPT faster or equal to ADO using the OLEDB provider.
>If you see some flaws in the code above by all means point those out, maybe I am missing something obvious on the SPT code. Notice that I am not setting any special options on either the ADO or SPT code, other than the cursor location of the ADO connection object.