> > It is quite ok, if the column containing the data can be casted to
> > CHAR(1). What do we do with other (for example, CHAR(5)
> > containing 'true' and 'false')?
> but if value = "true" -> value.charAt(0) is 't'
> and "YyTt1Oo".indexOf('t') is 3

ok, but let's assume that column contains 'off'. Then what? Well.. I
think this is just matter of taste. I prefer to check the complete
string to case insensitive equality to 'y', 'yes', 't', 'true', '1'
and 'on' rather then to the first letter of the string, as well as
to 'n', 'no', 'f', 'false', '0' and 'off' and throw SQLException in
all other cases.

> > And how to specify the backward
> > conversion in PreparedStatement.setBoolean(...) if the column in
> > CHAR(5)?
> As far as I understand a JDBC driver (and it's not that far... :) )
> I would say that setBoolean on a numeric field should set either 0
> or 1, and setBoolean on a CHAR field should set simply and
> always "T" or "F". The code proposed above is just to make the
> driver able to translate to a boolean
> more strings pattern than just t/true and f/false.
> ... anyway since this answer is quite trivial I think I didn't
> understand your question

Ok, if the column is numeric, then 1 and 0 are natural choices, if
column is CHAR(1) then you have to choose between 't'/'f', 'y'/'n'
and '1'/'0'.

Sure, the code is to make the driver understand more string
representation of true and false. But if you're connecting to
database that uses 'yes' for true and 'no' for false, and you're
accessing the field with rs.getBoolean(...) and get correct results,
then, when you invoke setBoolean(...) you should expect that driver
will store the 'yes' and 'no', but not 't' and 'f', since driver was
intelligent enough to understand the 'yes' and 'no' on read
operations.

I was thinking about creating a possibility of specifying the
conversion scheme with the connection parameters. You do pass
properties when obtaining the connection, so why do not specify the
default values for true and false there too?

Roman