Hi,

While working on the type 2 driver modifications im back at
FBDatabaseMetaData.java. This seems to be one of the most painfull
classes to work with due to the way it re-arranges the result set -
requiring access to the encodeXXX methods of XSQLVAR. It is even
more difficult to deal with when looked at from the perspective of a
GDS implementation that makes use of the java.nio.DirectBuffer
class.

Take for instance the getProcedures method. This uses the following
base SQL:

select
RDB$PROCEDURE_NAME as PROCEDURE_NAME,
RDB$DESCRIPTION as REMARKS,
RDB$PROCEDURE_OUTPUTS as PROCEDURE_TYPE
from
RDB$PROCEDURES
where
1 = 1 order by 1

It then reorganizes the result set before returning it to the
client. As far as I can see after trying a few things out in IB
Expert the following SQL appears to work and as far as I can see
would provide a ResultSet that could be returned directly to the
client:

select
null as PROCEDURE_CAT,
null as PROCEDURE_SCHEM,
RDB$PROCEDURE_NAME as PROCEDURE_NAME,
null as FUTURE1,
null as FUTURE2,
null as FUTURE3,
RDB$DESCRIPTION as REMARKS,
RDB$PROCEDURE_OUTPUTS + 1 as PROCEDURE_TYPE
from
RDB$PROCEDURES
where
1 = 1 order by 1

This would simplify the getProcedures - removing the need for it to
work with XSQLVAR's and encode data directly. From browsing through
this class it seems it may be possible to implement the other
methods in a similar way.

If I could make these changes it would make life much easier. So can
anyone see any potential problems with this or any reason why it
cannot be done this way ? Would it be OK if I made these changes
along with the class 2 driver modifications ?

Some input would greatly appreciated as I would like to proceed
without potentially wasting time going down a bad path.

(Please excuse the not normal email address)
Thanks
Ryan