Hi Daniel,
Please try to turn on *bytea as LO* option.
regards,
Hiroshi Inoue
(2013/12/18 9:48), Daniel Homerick wrote:
> When I use the SQLColAttribute function to get the either the
> SQL_DESC_LENGTH or SQL_DESC_OCTET_LENGTH attribute, a bytea column
> reports the “Max Varchar” configuration value (255 by default), even
> when the actual data length is longer. This appears to be the case when
> the “Unknown Sizes” configuration option is at either the default
> “Maximum” value, or the “Don’t Know” option.
>
> I ran into this as a problem when trying to determine an appropriate
> buffer size for use by SQLBindCol. When I would naively use the reported
> size for my buffer, a segfault was never far behind.
>
> In my case, I can’t particularly trust that the system will always be
> set up with the “Unknown Sizes” config option set to “Longest”. And
> since the “Max Varchar” is a user configurable value, I can’t just
> special case my code to treat 255 as a magic value. With the potential
> for crashing my app if the ODBC isn’t configured as expected, I’m
> currently thinking that I’ll need to always use SQLGetData over
> SQLBindCol when using Postgres and dealing with bytea columns.
>
> Is there some other function or attribute I should be using in order to
> determine a bytea column’s actual length?
>
> Alternatively, is there a function I can call to get the “Max Varchar”
> value, so that I can use it to compare (and not trust the value if it
> matches)?
>
> Are there other approaches that I should explore instead?
>
> As an aside, psqlODBC’s behavior here doesn’t really seem to jive with
> Microsoft’s ODBC documentation:
> http://msdn.microsoft.com/en-us/library/ms713558(v=vs.85).aspx
--
I am using the free version of SPAMfighter.
SPAMfighter has removed 1300 of my spam emails to date.
Get the free SPAMfighter here: http://www.spamfighter.com/len
Do you have a slow PC? Try a Free scan
http://www.spamfighter.com/SLOW-PCfighter?cid=sigen
