`DataSourceType` determines whether ODBC or OleDb (via ADO) is used. I do believe ADO mode is the default but I could be wrong. I never used the CursorAdapter because frankly the syntax and object model for that thing was horrendous (as was XmlAdapter but I needed to use that due to features that you couldn't get any other way).

+++ Rick ---

>Rick,
>
>CursorAdapters use ODBC just like remoteviews and SPT. I've been doing this for many years.
>
>Walter,
>
>>What I meant is that CA uses OleDb by default and if you are using the CA you should be using it with OleDb as it will provide better compatibility because it was designed much later than the ODBC interface in FoxPro.
>>
>>There's a separate connection string for OleDb but otherwise the behavior in the CA should be the same.
>>
>>Go to ConnectionStrings.com to find the appropriate connectionstring to use.
>>
>>+++ Rick ---
>>
>>>>>I was re-reading the thread (so that I can document my notes; otherwise, I will forget all this discussion by this coming Monday :)
>>>>>You said that CA does not work with ODBC but with OleDb. I am not arguing; I am sure you know what you are talking about. But my question is, how does changing the driver from "SQL Server" to "SQL Server Native Client 11.0" changes the OleDb? I thought that when I specify the connection via the "SQL Server" or "SQL Server Native Client 11.0", I am specifying the ODBC driver. But if I understand you correctly, the driver I specify affects the OleDB as well. Could you, please, if you have a free moment explain?
>>>>
>>>>ODBC and OleDb drivers are completely different animals and FoxPro interfaces with them completely differently (ie. Remove Views and SQLPassthrough use ODBC, DataAdapters use OleDb). OleDb is a COM based protocol, while ODBC is a raw API based protocol that Windows provides (on Windows anyway - on other platforms the drivers come from other sources). The OleDb driver support on FoxPro tends to have much better support for newer features, because a) it's much newer when it was introduced, and because types are translated through the Windows COM system rather than through FoxPro. The COM -> FoxPro translation can map better to FoxPro data than the full ODBC raw SQL data types.
>>>>
>>>>The ODBC interface in FoxPro can't deal with some of the type conversions that the ODBC drivers provide (not sure why - especially for strings) but I think it has to do with how the schema information is passed and processed by FoxPro. There was no VarChar(Max) when FoxPro was discontinued (I think maybe came out right around the same time) so FoxPro just doesn't know what to do with that. As I mentioned varchar(max) doesn't work because FoxPro's use of the ODBC driver can't figure out the width for the 'max' value and wasn't set up to map to memo automatically but it works fine with using a very large value as that value is turned into a memo. Not sure what that does to overhead/memory usage inside of the OleDb driver, but I suspect it's not a big deal as I've returned massive amounts of memo data with varchar(999999999) and didn't see a mem problem that would account for a 1/2 million records with 999999999 bytes per field :-)
>>>>
>>>>+++ Rick ---
>>>>
>>>Thank you for taking the time to reply to my question. But, I am still now clear about the following:
>>>
>>>In my application I specify the Driver when creating a connection handle to the SQL Server. The driver could be "SQL Server" or "SQL Server Native Client 11.0". There is NO other place where the driver is specified.
>>>
>>>Then, when creating the CursorAdapter object I set the CA.DataSourceType = "ODBC" (! Not OleDb!).
>>>The CursorAdapter DataSource = ConnectionHandle && Connection handle creates with the Driver ("SQL Server" or "SQL Server Native Client 11.00"
>>>Nowhere in my application I set the "OleDb"
>>>
>>>And since the CA DataSourceType is set to "ODBC" and DataSource is set to the Connection Handle, how does the CA uses OleDb?