Subject Re: OCTETS as binary (and another problem with CachedRowSetImpl)
Author Fabiano
Hi, Mark!

No, it doesn't work using octetsAsBytes

I´m using this URL:

Last time i looked at the code, this parameter had no effect.
I don´t remember exactly why, but the place it was implemented was never reached when column types was CHAR/VARCHAR.

I presume this is still the case.

If i remember correctly, the problem was happening here (FBField.pas, line 545). I´m almost sure field.sqlsubtype is never == 1 for CHAR/VARCHAR fields, what makes isOctetsAsBytes useless in this position. It makes a long time i traced this problem, sorry if i´m mistaken.

case Types.LONGVARCHAR :
// check whether OCTETS should be returned as byte[]
if (isOctetsAsBytes() && field.sqlsubtype == 1)
return getBytes();
return getString();

Is there a developer branch for 2.3? Is the change for OCTETS implemented? I need this feature badly, as all my PK columns are CHAR(16) OCTETS...



--- In, Mark Rotteveel <mark@...> wrote:
> On Thu, 19 Jul 2012 13:45:16 -0000, "Fabiano"
> <fabiano@...>
> wrote:
> > Hi all!
> >
> > It seems Jaybird is treating "CHAR/VARCHAR CHARACTER SET OCTETS"
> > internally as Strings. I personally don´t think it is correct, as OCTETS
> > are used to store binary data. What do you think about this?
> >
> > I tried to look at Jaybird code some months ago to offer a fix, but at
> > that time, it seemed to me it would need a bunch of changes to make it
> > work.
> The way Jaybird handles (VAR)CHAR CHARACTER SET OCTETS is going to change
> in Jaybird 2.3 (see section 'Handling (VAR)CHAR CHARACTER SET OCTETS as
> (VAR)BINARY type' in the releasenotes), the change was too complex to
> consider for Jaybird 2.2.
> You could check if providing connection property octetsAsBytes in your
> connection string is sufficient to make CachedRowSetImpl use it correctly
> as that property will make the ResultSetMetaData report the column as
> Mark