Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
ODBC Driver SQL Server vs SQL Server Native Client
Message
Information générale
Forum:
Visual FoxPro
Catégorie:
Base de données, Tables, Vues, Index et syntaxe SQL
Divers
Thread ID:
01677000
Message ID:
01677045
Vues:
63
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?

TIA


>Unfortunately this is a deep morass of ODBC hell that is very difficult (if not impossible to parse reliably) to fix with a single driver. CursorAdpater works because it doesn't use ODBC - it uses the OleDb driver, which has updated integration in VFP that supports translating newer types.
>
>re: ODBC, there's is a ton of discussion around different drivers and what they do and don't support on this West Wind Message Board Thread:
>
>Create Sql Server Tables Error
>
>My takeaway from that discussion was this: The safest choice for most things is to use the generic FoxPro ODBC driver, rather than the native drivers. That works with most things including Varchar(max). If you use newer ODBC features like JSON or XML fields etc. then use the SQL Native driver and **selectively** switch to that driver for those queries that require it. If necessary you can cast query selectors in the SQL to types that FoxPro can deal with (like casting varchar(max) to text for example or a fixed width).
>
>Some things are also helped by using unicode fields rather than ANSI fields in the database (ie. using nvarchar instead of varchar) as switching to Unicode and the unicode translations in the VFP ODBC interface performs some additional translation.
>
>+++ Rick ---
>
>
>>Hi,
>>
>>I have been testing my VFP 9 application with the SQL Server Native Client 11.0. I changed the type Text with Varchar(MAX). I use CursorAdapter.
>>
>>Here is what I come across.
>>1. Good thing is that where the data is retrieved and saved via CursorAdapter, I have no problems.
>>
>>2. Then I tried to get the data from the column of type Varchar(MAX) without CursorAdapter. I do SQL Select and then assign the value of the column to a variable. The variable is EMPTY.
>>
>>So, it appears - please correct me if I am wrong - that with the SQL Server Native Client 11.0 and type Varchar(MAX), I must always get the data via CursorAdapter. Correct?
>>
>>TIA
>>
>>UPDATE. Since most if not all of my reports get the data from the SQL Server by SQL Select, I need to find a way to MAP the VarChar(Max) to a MEMO field, without CursorAdapter. Is it possible? And if yes, how?
"The creative process is nothing but a series of crises." Isaac Bashevis Singer
"My experience is that as soon as people are old enough to know better, they don't know anything at all." Oscar Wilde
"If a nation values anything more than freedom, it will lose its freedom; and the irony of it is that if it is comfort or money that it values more, it will lose that too." W.Somerset Maugham
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform