I would agree about the *processing* differences. But depending on the needs of the application processing differences and data retrieval times could be completely separate matters. On C/S, n-tier & web apps other issues like scalability come into play and a central point to these is data retrieval speed, among others.

So that said I wouldn't dismiss considering data retrieval speeds because everyone in the company has Pentium III's and up. On the other hand not every application needs the fastest data access, and in such cases minor differences would be negligible. Bottom line is, it depends largely on the needs of the application.

>J.,
>
>Maybe we've reached thepoint onprocessor speed that even (formerly) significant PROCESSING differences are now negligible.
>
>Just a thought
>
>Jim Nelson
>
>>>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:
>>

Local lcStr, lnHan, oCn, oRS, lnRes, lnStart
>>
>>lcStr = "Driver=SQL Server;Server=myServer;Database=myDB;Trusted_Connection=Yes"
>>lcOLEDB = "Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;"
>>lcOLEDB = lcOLEDB + "Initial Catalog=myDB;Data Source=myServer"
>>
>>oRS = CreateObject("ADODB.Recordset")
>>oCn = CreateObject("ADODB.Connection")
>>*-- ADO times
>>oCn.CursorLocation = 3
>>oCn.Open(lcOLEDB)
>>lnStart = Seconds()
>>oRS = oCn.Execute("Select * From inpart")
>>? "ADO took (seconds): ", Seconds() - lnStart
>>oRS.Close
>>oCn.Close
>>*-- SPT times
>>lnHan = SQLStringConnect(lcStr)
>>lnStart = Seconds()
>>lnRes = SqlExec(lnHan, "Select * From inpart")
>>? "SPT took (seconds): ", Seconds() - lnStart
>>Use In sqlresult
>>SqlDisconnect(lnHan)

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