Please excuse my general ignorance of things Jaybird. I do have a
passing familiarity with Java and database related stuff, but I'm new to
Jaybird and things are working the way I, perhaps naively, think they
should.

The problem is related to endian-ness. It a nutshell, Jaybird doesn't work.

After the call to isc_dsql_fetch, JXSqlda::JXSqlda (JXSqlda constructor)
sucks data out of the XSQLDA, allocating characters arrays corresponding
to the data length plus a fudge. Sometime later, these character arrays
get copied into fresh new Java byte arrays and stashed in the Java class
XSQLVARImpl.. An actual ResultSet.getInt ends up with a call to

public int decodeInt(byte[] byte_int){
int b1 = byte_int[0]&0xFF;
int b2 = byte_int[1]&0xFF;
int b3 = byte_int[2]&0xFF;
int b4 = byte_int[3]&0xFF;
return ((b1 << 0) + (b2 << 8) + (b3 << 16) + (b4 <<
24));
}

While this might work on Intel or a VAX (god help us), it is the wrong
byte order for, say, a Solaris box. And by sheer bad luck, that happens
to be the platform of choice of a client.

Perhaps the embedded driver is not an official part of Jaybird -- it
certainly isn't on the binary kit. Or maybe it was intended for
development usage on Intel-only platforms (gratefully extended by AMD,
of course). And possibly my analysis of the code is all wet. But for
the time being, having integers come out with the byte order inverted is
inconvenient.

What, pray tell, is the official status of the embedded driver and to
whom should a humble supplicant address his prayers for relief?



[Non-text portions of this message have been removed]