> We already have a ResultSet implemented with three implementations,
> one inside of Vulcan, one in the layered IscDbc interface, and one
> inside the ODBC driver. Unless there is a very strong reason to the
> contrary, we don't need another bloody one.

If that's about the name, it can be changed. But I agree with Adriano
(and I wrote that already before) that type conversion is not needed
in our case.

Another issue are strings. You said that ResultSet::getString(int)
returns UTF-8 encoded string, which requires procedure to know how to
convert data from internal charset to UTF-8 and vice versa (not
talking about the inefficiency for all charsets that do not belong to
first 255 chars). The UTF-8 in getString() is great for Java, but most
likely will be a problem to all other implementations. The PARAMDSC
structure allows procedure to tell server in which encoding data are
passed (the sub_type field) and server just converts them into the
needed charset.

Roman