我对这段代码中的内容感到惊讶:
SQLUINTEGER uiCursorType;
SQLINTEGER iLength;
SQLRETURN sSQLReturn;
sSQLReturn = SQLGetStmtAttr( shStmtHandle, SQL_ATTR_CURSOR_TYPE, &uiCursorType, SQL_IS_UINTEGER, &iLength);
我最初被告知此处可能存在问题,因为当包含函数返回时,Visual Studio(远程)调试器会告诉我变量uiCursorType
附近存在堆栈损坏。进一步调查我发现它可能是正确的。执行SQLGetStmtAttr
函数后,uiCursorType
中的值为2
,iLength
中的值为8
。检查调试器中sizeof(uiCursorType)
和sizeof(SQLUINTEGER)
的值,它会为两者报告4
。但是我被引入相信iLength
的函数,该函数实际上写了8个字节。我没有看到代码如何更清楚地表明它期望与它提供的变量缓冲区匹配的值:SQLUINTEGER
和SQL_IS_UINTEGER
似乎非常匹配。这个功能在64位平台上有问题吗?
进行Google搜索时,我在http://lists.freedesktop.org/archives/libreoffice/2012-January/024859.html找到了某种似乎相关的补丁,但我不知道如何找到有关它的更多信息。是否有关于此问题的更多信息以及如何解决此问题?
答案 0 :(得分:0)
你不应该使用SQLULEN
作为缓冲区(你的uiCursorType
)吗?在64位SQLULEN
中定义为INT64
,这将是您正在观察的8字节。
Microsoft的文档SQL_ATTR_CURSOR_TYPE
(https://msdn.microsoft.com/en-us/library/ms712631%28v=vs.85%29.aspx)表示该值为SQLULEN
。
SQL_ATTR_CURSOR_TYPE(ODBC 2.0)
一个指定游标类型的SQLULEN值:
同样请注意,如果属性不是字符串或二进制属性(https://msdn.microsoft.com/en-us/library/ms715438%28v=vs.85%29.aspx),驱动程序很可能会忽略BufferLength
的值:
如果Attribute是ODBC定义的属性且* ValuePtr是整数,则忽略BufferLength。