Skip site navigation (1) Skip section navigation (2)

UUID returned as SQL_VARCHAR instead of SQL_GUID, contains no data

From: Daniel Homerick <daniel(dot)homerick(at)2d3sensing(dot)com>
To: "pgsql-odbc(at)postgresql(dot)org" <pgsql-odbc(at)postgresql(dot)org>
Subject: UUID returned as SQL_VARCHAR instead of SQL_GUID, contains no data
Date: 2012-10-10 15:17:23
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-odbc
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.

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.

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.

- Dan

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

pgsql-odbc by date

Next:From: Копыченко ПавелDate: 2012-10-12 14:29:20
Subject: Sorry to bother you. Please tell me exactly how the compiler was built ODBC
Previous:From: George WeaverDate: 2012-09-25 13:35:40
Subject: Application Name

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group