C++ SQLGetDiagRec在Unicode发布版本中导致崩溃

我在调用SQLGetDiagRec时遇到问题。它在ascii模式下工作正常，但在unicode模式下它会导致我们的应用程序崩溃，我就是不明白为什么。我能找到的所有文档似乎都表明它应该在内部处理ascii/unicode开关。我使用的代码是：

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;
}

一切正常，直到该函数尝试返回，然后应用程序崩溃。在调用get_sqlErrorInfo之后，它永远不会返回到代码行

我知道这就是问题所在，因为我已经输入了诊断代码，它通过了SQLGetDiagRec，OK，然后它取消了这个函数

如果我对SQLGetDiagRec行进行注释，它可以正常工作

无论是否运行release或debug，它在我的开发盒上都能正常工作

在此问题上的任何帮助都将不胜感激。

---

谢谢你，可能会有很多问题。首先，当你说：

m_oszerrorInfo = Msg;

m_oszerrorInfo的类型是什么？如果是指针，则存储指向局部变量（Msg）的指针。如果以后使用该指针，Msg将不再存在

---

其次，以下划线开头的名称将在名称空间范围内为编译器重新保存。为了不必担心这意味着什么，不要使用以下划线开头的名称。

我找到了正确的答案，所以我想我会把它包括在这里以供将来参考。我看到的文件是错误的。SQLGetDiagRec不处理使用SQLGetDiagRecW所需的Unicode。

问题可能出在

sizoef（Msg）

中。它应该是字符数：

sizeof(Msg)/sizoef(TCHAR)

---

嗨，尼尔，我真的不明白这句话：“其次，以下划线开头的名称将在名称空间范围内为编译器重新保存。”你能更好地解释一下吗？我很好奇谢谢你的回答。我很确定m_oszerrorInfo不是问题，因为即使没有那一行，问题也会发生，而且它不是指针。我加入它只是为了表明我们正在对返回的数据进行处理。我将尝试删除_名称，我们以前有一个开发人员经常这样做，我们无法说服他不这么做。@john-下划线名称不会是问题，但是爱迪生是C++标准，它指定某些名称是为了使用编译器和库编写器而保留的，而不应该在自己的代码中使用它们。以下划线开头的名称是此类名称中的一类。您可以使用定义的_UNICODE和UNICODE编译项目，这将把SQLGetDiagRec映射到SQLGetDiagRecW。在Visual Studio中，最简单的方法是转到项目的属性General->Character Set=Use Unicode Character Set。我确实在windows代码中看到它看起来应该映射，但是它崩溃了，直到我明确地这样做了：35; ifdef(u Unicode nRet=SQLGetDiagRecW）（_htype，_hndle，i，SqlState，&NativeError，Msg，SQL_MAX_MESSAGE_LENGTH，&MsgLen）；#else nRet=SQLGetDiagRec（_htype，_hndle，i，SqlState，&NativeError，Msg，SQL_MAX_MESSAGE_LENGTH，&MsgLen）#end如果我们确实同时定义了UNICODE和UNICODE，并且字符集被设置为UNICODE字符集，但显然由于某种原因，映射不起作用。