UUID returned as SQL_VARCHAR instead of SQL_GUID, contains no data

I tried reporting this bug once before, but I hadn't subscribed to the pgsql-odbc list at that time and I think my emails must be permanently stuck in a spam filter limbo.

Summary:
When selecting a UUID column, it is reported as a SQL_VARCHAR. Binding the column and fetching never retrieves any data for the column.

Versions affected:
x64 ANSI on Windows, at least since 9.01.0100, but possibly before. Does not affect the Unicode or x86 version.

Details:
I'm using ODBC directly from C++ code. When I select a uuid column and check the type (SQL_DESC_CONCISE_TYPE via SQLColAttribute) it is reported as an SQL_VARCHAR instead of an SQL_GUID. The SQL_DESC_OCTET_LENGTH (SQLColAttribute) is reported as 16, however (vs. the 36 that you would expect for a string representation). When I use SQLBindCol and SQLFetchScroll to retrieve the column, the size ("StrLen_or_Ind" variable from the SQLBindCol call) is reported as 36 bytes. Although that reported length is consistent with a string representation, no data is placed in the bound buffer ("TargetValuePtr") after the fetch. Other columns that are selected/bound/fetched at the same time are correctly retrieved.

I looked at the psqlodbc source, and the problem only shows up on x64 ANSI because it uses a different value for the ODBCVER preprocessor define.

In the win32.mak file, on lines 119-124, the preprocessor define "ODBCVER" is set to 0x0350 (ANSI) or 0x0351 (UNICODE).
In the win64.mak file, on lines 128-133, "ODBCVER" is set to 0x0300 (ANSI) or 0x0351 (UNICODE).

Searching the psqlodbc code for "ODBCVER" finds that there are a lot of "#if (ODBCVER >= 0x0350)" conditions to use SQL_GUID, falling back using a VARCHAR (or WVARCHAR) otherwise. Apparently the fallback code path has some bugs (it appears to be inconsistently implemented). I don't think that the x64 ANSI version should be using the fallback path, though. As a user, I would certainly much prefer that all the psqlodbc driver versions were using the same ODBC version.

I hope that a fix for this can make it into the next release.

Cheers,
- Dan

-------------------------------------------------------------------------------------------
Dan Homerick daniel(dot)homerick(at)2d3sensing(dot)com<mailto:daniel(dot)homerick(at)2d3sensing(dot)com>
Software Engineer Tel: 650-627-7624
2d3Sensing http://www.2d3sensing.com