Non è possibile convertire correttamente i dati di tipo carattere da un client a un server usando il driver ODBC di SQL Server se la tabella codici del client è diversa dalla tabella codici del server

Questo articolo consente di risolvere un problema che causa una conversione errata dei dati client quando si usa il driver ODBC di SQL Server.

Versione originale del prodotto: SQL Server
Numero KB originale: 234748

Sintomi

Quando si usa MDAC 2.1 o versione successiva del driver ODBC di SQL Server (versione 3.70.0623 o successiva) o il provider OLEDB (versione 7.01.0623 o successiva), in alcune circostanze è possibile che si verifichi la conversione dei dati di tipo carattere dalla tabella codici client alla tabella codici del server, anche quando Autotranslation è disabilitato per la connessione.

Causa

Autotranslation non è l'unico meccanismo che può comportare la conversione della tabella codici. Il driver ODBC di SQL Server 7.0 e il provider OLEDB introducono un nuovo comportamento durante la connessione a MSDE 1.0, SQL Server 7.0 o versioni successive di uno di questi. Tutte le istruzioni SQL inviate come evento linguistico vengono convertite in Unicode nel client prima di essere inviate al server. L'effetto finale è simile a un Autotranslation di tutti i dati che passano dal client al server tramite un evento linguistico, indipendentemente dall'impostazione corrente Autotranslation per la connessione. Non presenterà alcuna difficoltà, tranne quando si tenta di archiviare dati di caratteri non tradotti da una tabella codici diversa dalla tabella codici di SQL Server.

Soluzione alternativa

Non archiviare i dati della tabella codici X in una tabella codici DI SQL Server (ad esempio, tabella codici 950 dati in un server tabella codici 1252). Sebbene ciò sia stato possibile in alcune circostanze con le versioni precedenti di SQL Server, non è sempre stato supportato. Per un'istanza di SQL Server 1252, qualsiasi carattere, ma un carattere 1252 non è valido. I dati di tipo carattere non Unicode di una tabella codici diversa non verranno ordinati correttamente e, nel caso di dati DBCS (Dual Byte), SQL Server non riconoscerà correttamente i limiti dei caratteri. Può causare problemi significativi.

La scelta migliore per la tabella codici di SQL Server è la tabella codici dei client che accederanno al server.

Il server e il client possono avere tabelle codici diverse, ma è necessario assicurarsi che la conversione automatica sia abilitata nel client in modo da ottenere una traduzione corretta dei dati da e verso la tabella codici del server in tutti i casi.

Se il server deve archiviare i dati da più tabelle codici, la soluzione supportata consiste nell'archiviare i dati in colonne Unicode (NCHAR/NVARCHAR/NTEXT).

Se la situazione richiede di archiviare i dati della tabella codici X in una tabella codici di SQL Server Y, esistono solo due modi per eseguire questa operazione in modo affidabile:

• Archiviare i dati in colonne binarie (BINARY/VARBINARY/IMAGE).
• Scrivere l'applicazione per usare le chiamate di procedura remota (RPC) per tutte le istruzioni SQL che gestiscono i dati di tipo carattere. I dati inviati tramite un evento RPC non sono soggetti alla conversione. Non esiste nulla a livello di driver o DSN che è possibile eseguire per modificare il tipo di eventi inviati. Se un comando viene inviato come linguaggio o evento RPC dipende interamente dalle API e dalla sintassi scelta dal programmatore quando l'applicazione viene scritta.

Ulteriori informazioni

Le caselle di controllo Esegui traduzione per i dati di tipo carattere nelle applicazioni ODBC più recenti converte i dati di tipo carattere dalla tabella codici client alla tabella codici del server prima di inviare i dati al server, usando Unicode come supporto di traduzione. Tuttavia, il driver ODBC di SQL Server 3.7 converte anche tutte le istruzioni SQL inviate come evento di linguaggio in Unicode prima di inserirle in rete, che ha un effetto simile a Autotranslation ma non è governato dall'impostazione di conversione automatica. Al contrario, i dati di tipo carattere che passano di nuovo dal server ai client rispettano il flag di traslazione automatica; se la traslazione automatica è disattivata, i dati arrivano all'applicazione client con gli stessi codici di carattere dei dati presenti nel server. Analogamente, la conversione dei dati per gli eventi RPC da client a server può essere disabilitata disattivando la conversione automatica. Script semplice che illustra come il comportamento influisce sugli eventi del linguaggio seguenti. Questo esempio è stato eseguito da Query Analyzer in un client della tabella codici 1252 che si connette a un server tabella codici 437:

-- Turn Autotranslation off here.
 USE tempdb
 GO
 CREATE TABLE t1 (c1 int, c2 char(1))
 GO

-- Enter a yen character, using the keystroke ALT-0165.
 INSERT INTO t1 VALUES (1, '¥') 
 SELECT c1, c2, ASCII (c2) FROM t1

c1 c2 
 ----------- ---- ----------- 
 1  157

(1 row(s) affected)

Di seguito viene illustrato l'esempio precedente:

• Anche se Autotranslation era spento durante questo batch, il codice carattere 165 (yen nella tabella codici 1252) è stato convertito in 157 (yen nella tabella codici 437). Questo perché il driver ODBC ha convertito la stringa SQL in Unicode prima di inviarla al server, quindi il server è stato in grado di convertirlo nel carattere appropriato per l'archiviazione nella tabella codici 437.
• Quando il client ha eseguito un'istruzione SELECT per recuperare i dati archiviati, il carattere 157 è arrivato non tradotto nel client (157 viene visualizzato come casella "" in una tabella codici 1252 client). Ciò è dovuto al fatto che la conversione descritta in questo articolo si applica solo ai dati inviati dal client al server, non dal server al client. I dati non sono stati convertiti perché l'impostazione Autotranslation è disattivata.

-- Turn Autotranslation back on before running the following batch.
 INSERT INTO t1 VALUES (2, '¥')
 SELECT c1, c2, ASCII (c2) FROM t1

c1 c2 
 ----------- ---- ----------- 
 1 ¥ 157
 2 ¥ 157

(2 row(s) affected)

In questo caso, l'attivazione Autotranslation di nuovo non ha avuto alcun effetto sulla conversione dal client al server , ovvero la stessa conversione corretta dal codice carattere 165 al codice carattere 157, ma ha avuto un effetto sui dati recuperati dal server. Quando l'istruzione SELECT viene eseguita questa volta (con Autotranslation on), i simboli yen vengono visualizzati correttamente nella tabella codici 1252 applicazione perché sono stati convertiti dal codice carattere 157 al codice carattere 165 dal Autotranslation meccanismo.

Questo comportamento verrà visualizzato (conversione di eventi del linguaggio in Unicode nel client) quando si usa un driver ODBC di SQL Server versione 3.70 o successiva e ci si connette a SQL Server 7.0 o versione successiva. Non si verificherà quando si usano driver ODBC meno recenti o quando si usa il driver 3.7 per connettersi a SQL Server 6.5 o versioni precedenti. Inoltre, se si archiviano i dati in colonne Unicode (NCHAR/NVARCHAR/NTEXT) la conversione non sarà un problema.

Per altre informazioni sul modo in cui i dati di tipo carattere sono rappresentati in SQL Server 2005, vedere Dati carattere rappresentati in modo non corretto quando la tabella codici del computer client è diversa dalla tabella codici del database in SQL Server 2005.