On Fri, 10 Aug 2001 11:07:45 -0400, you wrote:
>In dbMeta1, the test for supportsStoredProcedures fails consistently.
>The method returns false, but the test harness is expecting true and
>considers false to be an invalid response. The reason for this is that
>the JDBC test suite is doing tests for J2EE compliance of the JDBC
>driver being tested, and one of the conditions is that
>supportsStoredProcedures should always return true. For regular JDBC
>compliance, returning false is alright.
I'm not sure if this is true. The JDBC book
(http://java.sun.com/docs/books/jdbc/) says in the description
of supportsStoredProcedures: "checks whether this database
supports stored procedure calls using the stored procedure
escape syntax". And in section A.1.3: "... must be supported by
a JDBC Compliant driver... Where appropriate, an escape syntax
must be included for stored procedures, ...". I see no mention
of J2EE with respect to this requirement.
>In the PostgreSQL driver, there are some methods that throw
>SQLExceptions because they are not implemented yet (isCatalogAtStart,
>getCatalogSeparator, getUDTs). But other unimplemented methods, such as
>getTablePrivileges, getVersionColumns, getExportedKeys, and
>getCrossReference return null. Until they are implemented, they should
>throw an SQLException.
So noted on http://lab.applinet.nl/postgresql-jdbc/ under
"miscellaneous".
As an aside, I've just updated this page with an explanation of
the Blob/Clob/Lob issues and the proposal from Barry Lind, as
well as some other issues that have been posted on this list.
>null != empty ResultSet, so getTypeInfo should not have a fallback
>return value of null, but rather should throw an SQLException when the
>metadata is not available.
So noted under "DatabaseMetaData".
>In general, I think that better checking for
>unavailable metadata can be done.
I'm not sure what you mean by that. But maybe I'm the problem,
its getting late :-)
>The SQLExceptions thrown by unimplemented methods will be caught by the
>JDBC test harness and the tests will be flagged as errors due to the
>fact, again, that the test suite is testing for J2EE compliance: all
>methods should be implemented and none should throw exceptions.
They're allowed to throw exceptions by the signature, but they'd
better not when the test is running :-)
>For more information on the JDBC and J2EE, see the J2EE Api,
>section 6.2.2.3.
Hmmm... what book are you refering to? I have the "Java 2 EE
Platform and Components Specifications", but it doesn't have a
section 6.2.2.3.
Regards,
René Pijlman