Re: Windows, ODBC drivers and strange points ...

> -----Original Message-----
> From: Marten Feldtmann [mailto:m.feldtmann@xxxxxxxxxxx] 
> Sent: 17 November 2005 17:05
> To: Dave Page
> Subject: Re: [ODBC] Windows, ODBC drivers and strange points ...
> 
> The same test I desribed in the first posting
> 
> We have a table like:
> 
> create table "TPERSON" ("ALLCSTVIEW" CHAR(1))
> 
> and does a select *  from  ... and opens
> a cursor for the result and queries all
> columns the following way:
> 
> Now IBM Smalltalk calls OdbcSQLDescribeCol
> and gets 1 for this column as size in the
> return parameter cbPrecision.
> 
> And with an alternate call it queries
> via OdbcSQLColAttribute  with parameter
> Sql_Column_Length  and this returns 3.

Well, I don't know how Smalltalk is renaming things, but if I use
SQL_DESC_LENGTH, I get 1 as expected. I do get 3 is if I use
SQL_DESC_OCTET_LENGTH. The spec says:

----
This SQLINTEGER record field contains the length, in bytes, of a
character string or binary data type. For fixed-length character or
binary types, this is the actual length in bytes. For variable-length
character or binary types, this is the maximum length in bytes. This
value always excludes space for the null-termination character for
implementation descriptors and always includes space for the
null-termination character for application descriptors. For application
data, this field contains the size of the buffer.
----

psqlODBC is returning the size using pgtype_transfer_octet_length()
which it goes to great lengths to calculate. I'm not sure I fully
understand why it's doing what it does, and frankly I'm wary of changing
it as it was written by Hiroshi Inoue who definitely understood the spec
better than I do!!

Can anyone else comment on this?

Regards, Dave.

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster