-----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-----
