db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmars...@Sourcery.Org>
Subject Re: On DERBY-107 : ODBC Metadata functions
Date Thu, 27 Jan 2005 17:46:17 GMT
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:
> 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.
> At this point, it seems like there are two possibilities for handling
> this.

> 1) Use VTIs (Virtual Table Interfaces)
> 2) Do some "under-the-covers" work to automatically generate
> ODBC-compliant SQL statements based on the existing JDBC statements,
> 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

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


View raw message