Re: On DERBY-107 : ODBC Metadata functions

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Army wrote:

> Having seen no other posts on this since my most recent one, this is
> where we stand right now with ODBC metadata support for ODBC clients
> running against Derby Network Server:
>
[snip]
>
> It turns out that, aside from "getProcedureColumns", the only other
> metadata function for which ODBC specifies columns that JDBC does not
> have is "getTypeInfo".  That said, do people think it's okay to add an
> extra column to the result set of this function, or not?  The Java spec
> doesn't explicitly say that it's okay, so it's not as clean as it is
> with getProcedureColumns...
>
> That's one option (add the columns to both JDBC and ODBC metadata
> resultsets). The other is to use whatever means are deemed best (by the
> Derby community) to resolve the following issue:

Well, I figure as long as we have to deal with item name changes too for
getTypeInfo, might as well make the resultset right.


>> 2) Column Name changes.
[snip]
> At this point, it seems like there are two possibilities for handling
> this.

> 1) Use VTIs (Virtual Table Interfaces)
[snip]
> 2) Do some "under-the-covers" work to automatically generate
> ODBC-compliant SQL statements based on the existing JDBC statements,
[snip]
> Anyone have any preferences/feedback/knowledge to throw in?

I prefer option #1 because I understand it #:). I am not quite sure how
all that query rewriting is going to work, when the stored prepared
statements would get built and exactly how it will all work.

>
> Thanks!
> Army
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFB+SjpG0h36bFmkocRAtyEAKCeCl0MN+9uGOEP1It87uD9+MhSxACguwck
Dp2UQPsrEJ2UqgBMqctL8YM=
=3Jtd
-----END PGP SIGNATURE-----