Hi,

There is a far easiear way round this - and things wont be as bad as
they did seem from a java.nio.DirectBuffer persepective.

Thanks
Ryan


--- In Firebird-Java@yahoogroups.com, "ryanb486" <ryan.baldwin@n...>
wrote:

> 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