SQLGetDiagRecW is buggy in the ODBC driver for linux

Question

We have been using the Microsoft ODBC Driver 11 for SQL Server on Linux with a Qt based application and noticed that error messages are truncated and end with a string of garbage.
We traced it down to the point where the driver manager in unixODBC calls SQLGetDiagRecW on the driver.
This is the signature of the SQLGetDiagRec function, which shares the interface with its wide char counterpart, as described in this documentation page: https://msdn.microsoft.com/en-us/library/ms716256(v=vs.85).aspx
SQLRETURN SQLGetDiagRec(
SQLSMALLINT HandleType,
SQLHANDLE Handle,
SQLSMALLINT RecNumber,
SQLCHAR * SQLState,
SQLINTEGER * NativeErrorPtr,
SQLCHAR * MessageText,
SQLSMALLINT BufferLength,
SQLSMALLINT * TextLengthPtr);
The function is called twice, once with a null pointer as
MessageText to obtain the length of the message text in characters in the
TextLengthPtr parameter. Once this is obtained, Qt then allocates a buffer large enough to hold that number of characters.
It is important to note that we are dealing with wide characters here, so each character is two bytes.
Now Qt calls SQLGetDiagRecW, this time with MessageText pointing to the newly allocated buffer and it's length (in characters) as the BufferLength parameter.
Only now the function seems to interpret this BufferLength as size of the buffer in bytes, and since it has not enough space to write its text, it writes only half of the message in MessageText and returns SQL_SUCCESS_WITH_INFO.
Unfortunately Qt treats this return code the same way it treats a SQL_SUCCESS so we never get the other half.
However, the fact remains that the driver is outputting sizes in characters and then interpreting them as sizes in bytes.
In the documentation linked above, both BufferLength and TextLengthPtr are described in terms of
characters. But I also notice that a bit further down, it mentions StringLengthPtr in terms of
bytes.
We found also this KB article ( https://support.microsoft.com/en-us/kb/kbview/243526?wa=wsignin1.0 ) that seems to imply that the description was such that matches the observed behavior, but while the description has been changed, the wrong behavior
remains.
I've tried to report this in the Connect site but it has been impossible, I always get an error saying that I'm not authorized. Anybody knows how else I can reach the developers?
For now we have patched unixODBC to duplicate the value of the output TextLengthPtr on the first call, so that Qt allocates twice the amount of memory than it is really needed. This is done as a safer counterpart to telling
the driver we have double the space, since that would bring problems if and when the driver is fixed.

Answer 1

I suspect you just need to get rid of the 'as rcount' clause in your select statement.
Justin