2009-05-06 4 views
1

Ich habe ein Problem mit dem Aufruf von SQLGetDiagRec. Es funktioniert gut im ASCII-Modus, aber in Unicode verursacht es unsere App zum Absturz, und ich kann einfach nicht sehen, warum. Die gesamte Dokumentation, die ich gefunden habe, scheint darauf hinzudeuten, dass sie den ascii/unicode-Schalter intern handhaben sollte. Der Code, den ich verwende ist:SQLGetDiagRec verursacht Absturz in Unicode-Versionserstellung

void clImportODBCFileTask::get_sqlErrorInfo(const SQLSMALLINT _htype, const SQLHANDLE _hndle) 
{ 
SQLTCHAR  SqlState[6]; 
SQLTCHAR  Msg[SQL_MAX_MESSAGE_LENGTH]; 
SQLINTEGER NativeError; 
SQLSMALLINT i, MsgLen; 
SQLRETURN  nRet; 

memset (SqlState, 0, sizeof(SqlState)); 
memset (Msg, 0, sizeof(Msg)); 

// Get the status records. 
i = 1; 

//JC - 2009/01/16 - Start fix for bug #26878 
m_oszerrorInfo.Empty(); 

nRet = SQLGetDiagRec(_htype, _hndle, i, SqlState, &NativeError, Msg, sizeof(Msg), &MsgLen); 
m_oszerrorInfo = Msg; 
} 

alles ist in Ordnung, bis diese Funktion versucht, zurückzukehren, dann stürzt die App ab. Nach dem Aufruf von get_sqlErrorInfo wird die Codezeile nicht zurückgenommen.

Ich weiß, das ist, wo das Problem liegt, weil ich Diagnose-Code eingefügt habe und es über die SQLGetDiagRec in Ordnung kommt und es diese Funktion erfüllt.

Wenn ich die SQLGetDiagRec-Zeile kommentieren, funktioniert es gut.

Es funktioniert immer gut auf meiner Entwicklungs-Box, ob es Release oder Debug läuft.

Jede Hilfe zu diesem Problem würde sehr geschätzt werden. Danke

Antwort

1

Nun, ich fand die richtige Antwort, also dachte ich, ich würde es hier für zukünftige Referenz aufnehmen. Die Dokumentation, die ich gesehen habe, war falsch. SQLGetDiagRec behandelt nicht Unicode, das für die Verwendung von SQLGetDiagRecW benötigt wird.

+0

Sie könnten das Projekt mit _UNICODE und UNICODE definiert haben, die SQLGetDiagRec zu SQLGetDiagRecW zugeordnet hätten. In Visual Studio besteht die einfachste Möglichkeit darin, zu den Eigenschaften Ihres Projekts zu gelangen. Allgemein-> Zeichensatz = Unicode-Zeichensatz verwenden. –

+0

ich sehe in der Windows-Code, der es so aussieht, wo es sich shoudl, aber es wurde abstürzt, bis ich exlicitly tat #ifdef _UNICODE \t \t nRet = SQLGetDiagRecW (_htype, _hndle, i, SqlState & Native, Msg, SQL_MAX_MESSAGE_LENGTH , & MsgLen); #else \t \t nRet = SQLGetDiagRec (_htype, _hndle, ich, SqlState, & NativeError, Msg, SQL_MAX_MESSAGE_LENGTH, & MsgLen); #endif Wir haben definitiv sowohl _UNICODE und UNICODE definiert und der Zeichensatz ist auf den Unicode-Zeichensatz eingestellt, aber anscheinend aus irgendeinem Grund funktionierte das Mapping nicht. –

0

Ein paar mögliche Probleme. Zuerst, wenn Sie sagen:

m_oszerrorInfo = Msg; 

Was ist der Typ von m_oszirrorInfo? Wenn es sich um einen Zeiger handelt, speichern Sie einen Zeiger auf eine lokale Variable (Msg). Wenn Sie diesen Zeiger später verwenden, wird Msg nicht mehr vorhanden sein.

Zweitens werden Namen, die mit einem Unterstrich beginnen, für den Compiler im Namespace-Bereich erneut angegeben. Um sich nicht darum kümmern zu müssen, was dies bedeutet, verwenden Sie keine Namen, die mit Unterstrichen beginnen.

+0

Hallo Neil, habe ich nicht wirklich diesen Satz verstehen: „Zweitens Namen, die mit einem Unterstrich beginnen, sind für den Compiler auf Namespacebereich rerved.“ Könnten Sie das bitte besser erklären? Ich bin neugierig –

+0

Danke für Ihre Antwort. Ich bin ziemlich sicher, dass m_oszirrorInfo nicht das Problem ist, da das Problem auch ohne diese Zeile auftritt und es kein Zeiger ist. Ich habe es nur eingefügt, um zu zeigen, dass wir etwas mit den zurückgegebenen Daten machen. Ich werde versuchen, die _Namen zu entfernen, das ist ein Entwickler, den wir immer hatten, und das konnten wir nicht überzeugen. –

+0

@john - Die Unterstrichnamen werden nicht das Problem sein, aber sie sind schlechte Praxis. –

1

Das Problem liegt wahrscheinlich in der sizoef(Msg). Es sollte die Anzahl der Zeichen:

sizeof(Msg)/sizoef(TCHAR) 
+0

oder verwenden Sie '_countof (Msg)' – wimh

Verwandte Themen