Re: Oracle JDBC error - SOLVED!

Galen Boyer wrote:

> I'm not sure how jdbc is supposed to echo anything back to
> anywhere. An exception is an object. What Peter would have
> seen is a stack trace from the exception being hit.

> Maybe the exception object needs to be amended so as to put
> more juicy stuff in the correct section of the exception
> object.

Galen: this is exactly what I meant; the java Exception object has a method getMessage() -- actually its inhertee class Throwable has this method. The additional diagnostics (juicy stuff) I referred to, i.e., the location of the syntax error, could be stuffed in here. Either there, or in another String method SQLException.getSQLState(). By calling one of these messages, and displaying or logging the String, the app effectively echoes back the query.

> The OCI driver would be, the thin driver would not. Which is
> what I'm guessing to really be the issue. I believe java wants
> the same exact behaviour from its OCI and thin layers.

I can't see any reason why an OCI-based driver should have to suffer from the same limits as a "thin" driver, so long as both obey the JDBC spec. All JDBC specifies is that an Exception object be thrown, which has a message in the form of some String of text. That the OCI version would provide a richer diagnostic seems a useful feature, not a bug or limitation.

> Imagine if the exception handling mechanism coded by the client
> of the driver looked for a certain error and did something when
> it was hit. If the OCI driver returned a different error than
> the thin driver, then the substitution of different drivers
> might break the codebase.

Actually, this particular case (pls. review the thread if you have not followed it from the beginnging) involved an error fully identified by its ORA-nnnnn error number. Thus the issue of not being able to identify the error, at least by its Oracle error code, does not exist here in this case.

> You need to be barking at Oracle directly. It is their
> driver's not being verbose enough.

I've no interest in barking since I've long ago since found better alternatives to Java and JDBC. The purpose of my pointing out that a solution was possible was to assist the original poster, and anyone else who needed such a JDBC enhancement, to the end that they could know such an enhancement was feasible given the capabilities of OCI.

        Hope that helps to clarify,

        John Hinsdale Received on Tue Jul 31 2007 - 09:36:16 CDT