> -----Original Message-----
> From: Marten Feldtmann [mailto:m(dot)feldtmann(at)t-online(dot)de]
> 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?
pgsql-odbc by date
|Next:||From: Leendert Paul Diterwich||Date: 2005-11-18 14:04:44|
|Subject: Update: Visual Studio 2005 not happy with postgresql|
|Previous:||From: noreply||Date: 2005-11-17 14:57:03|
|Subject: [ psqlodbc-Bugs-1000422 ] Couldn't compile 08.01.0101 with Unix PG 7.4.5 development environment|