2009-07-02 14 views
0

Zusammenfassung: Ich versuche, eine Zeichenfolge in eine Spalte des Typs Varchar (Max) mit ODBC und SQL Server 2005 zu schreiben. Es schlägt fehl, wenn die Länge der Zeichenfolge ist größer als 8000. Hilfe!Wie schreibe ich in eine Varchar (Max) Spalte mit ODBC

Ich habe einige C++ - Code, der ODBC (SQL Native Client) verwendet, um eine Zeichenfolge in eine Tabelle zu schreiben. Wenn ich die Spalte von, sagen wir, varchar (100) varchar (max) und versuchen Sie ändern, um eine Zeichenfolge mit einer Länge von mehr als 8000 zu schreiben, schlägt der Schreib mit dem folgenden Fehler

[Microsoft] [ODBC SQL Server Treiber] Zeichenkette Daten, Recht Abschneiden

So kann mir jemand beraten, ob dies getan werden kann, und wie?

Einige Beispiele (nicht Produktion) Code, der zeigt, was ich versuche zu tun:

SQLHENV hEnv = NULL; 
SQLRETURN iError = SQLAllocEnv(&hEnv); 

HDBC hDbc = NULL; 
SQLAllocConnect(hEnv, &hDbc); 

const char* pszConnStr = "Driver={SQL Server};Server=127.0.0.1;Database=MyTestDB"; 
UCHAR szConnectOut[SQL_MAX_MESSAGE_LENGTH]; 
SWORD iConnectOutLen = 0; 
iError = SQLDriverConnect(hDbc, NULL, (unsigned char*)pszConnStr, 
         SQL_NTS, szConnectOut, 
         (SQL_MAX_MESSAGE_LENGTH-1), &iConnectOutLen, 
         SQL_DRIVER_COMPLETE); 

HSTMT hStmt = NULL; 
iError = SQLAllocStmt(hDbc, &hStmt); 

const char* pszSQL = "INSERT INTO MyTestTable (LongStr) VALUES (?)"; 
iError = SQLPrepare(hStmt, (SQLCHAR*)pszSQL, SQL_NTS); 

char* pszBigString = AllocBigString(8001); 
iError = SQLSetParam(hStmt, 1, SQL_C_CHAR, SQL_VARCHAR, 0, 0, (SQLPOINTER)pszBigString, NULL); 

iError = SQLExecute(hStmt); // Returns SQL_ERROR if pszBigString len > 8000 

Die Tabelle MyTestTable enthält eine einzelne colum definiert als varchar (max). Die Funktion AllocBigString (nicht gezeigt) erzeugt eine Zeichenfolge beliebiger Länge.

Ich verstehe, dass frühere Versionen von SQL Server 8000 Zeichen auf Varchars begrenzt haben, aber warum geschieht das in SQL 2005 nicht?

Danke, Andy

Antwort

1

Sie sicher, dass Sie den SQL Native Treiber für das Jahr 2005 laden, nicht der alte Treiber für das Jahr 2000? Der native Treibername ist {SQL Server Native Client 10.0} für 2k8 oder {SQL Native Client} für 2k5

Die Fehlermeldung ODBC SQL Server Driver scheint den alten 2k Fahrer anzuzeigen (ich falsch sein kann, hat ODBC nicht berührt in wie 10 Jahren jetzt).

+0

Danke Remus! Du hattest recht, ich habe den falschen Fahrer benutzt. Als ich das geändert habe, hat es funktioniert. Für den Datensatz verwendete ich die folgende Verbindungszeichenfolge: Treiber = {SQL Native Client}; Server = 127.0.0.1; Datenbank = MyTestDB; Das ist nicht ganz dasselbe wie der Name des Treibers, den Sie angegeben haben, aber Ihre Aussage hat mich auf die Antwort hingewiesen. Nochmals vielen Dank - sehr geschätzt. Andy –

+0

Anscheinend kann ich nicht die Herausforderung der Kopie einfügen einen Namen von MSDN zu einer Antwort einfügen lol. Richtig, der Name ist {SQL Native Client}, ich werde meinen Beitrag auch reparieren, für andere Google-Sake. –

1

Es stellt sich heraus, dass, obwohl das Update für SQLSetParam funktioniert, es für SQLBindParameter nicht funktioniert.

Zum Beispiel:

int iLength = 18001; 
char* pszBigString = new char[iLength + 1]; 
memset(pszBigString, 'a', iLength); 
pszBigString[iLength] = 0; 
LONG_PTR lLength = SQL_NTS; 
::SQLBindParameter(hStmt, 1, SQL_PARAM_INPUT, 
       SQL_C_CHAR, 
       SQL_VARCHAR, 
       iLength, 0, pszBigString, iLength * sizeof(TCHAR), 
       &lLength); 

in denselben 22001 führt "String-Daten direkt truncation" Fehler, unabhängig davon, welcher Treiber verwendet wird.

In der Tat haben meine Experimente gezeigt, dass Sie nicht tatsächlich müssen Version 10 des Client-Treibers installieren müssen. Stattdessen sollten Sie SQL_LONGVARCHAR anstelle von SQL_VARCHAR verwenden, wenn Sie erwarten, dass die Länge Ihrer Zeichenfolgen 8000 Zeichen überschreitet. Sie könnten möglicherweise eine Massensuche durchführen und ersetzen, aber es ist möglich, dass SQL_LONGVARCHAR eine Art von Strafe (obwohl das reine Spekulation ist; es ist ein "erweiterter Datentyp").

Ich habe dies erfolgreich mit beiden Treiber unter Windows XP getestet:

  • {SQL Server} 2000.85.1117.00 (04/08/2004)
  • {SQL Server Native Client 10.0} 2007.100.1600.22 (10/07/2008)
Verwandte Themen