> I was hoping to get back the ascii value of the character.

This is not defined in JDBC specs. You can always use ASCII() function (if
you define corresponding UDF) in your SELECT (it will automatically convert
data to a numeric column).

> It probably makes more sense to get back a numeric value.

At least that's how I understand the specification.

> The problem I have is that I quickly wrote a class that, given a
> ResultSet and an object, will use introspection on the object to
> know how to get column values from the ResultSet and set them on the
> object. If the matching setter for the object takes a char, there is
> no output from a ResultSet getter that I can pass in directly to the
> setter.

It would make more sense to use ResultSet.getString().charAt(0) (and not
ResultSet.getBytes()[0]). This code will handle the encoding conversion
correctly.

> BTW, what do you mean by "even more?" I can extend this class to
> take advantage of Jaybird enhancements.

There's no new getters or setters. Enhancements were done to:

- more conversions are available (for example LONGVARBINARY also provides
getBinaryStream() method). I do not have the conversion table, so you have
to check the code. Though I would not do this, but stick to the
specification.

- it was before (and probably still is) that PreparedStatement.setXXX method
could be called only with the objects of the default mapping (i.e. where the
the capital "X" stays in the table). JayBird also provides conversion for
PreparedStatement.setXXX for the mapping with "x" from the table. So to say,
JayBird is symmetric in regard to getters in ResultSet and setters in
PreparedStatement.

But again, I would stick to the specification.

Roman