Armin Waibel wrote:
If this is the case I think the driver has a somewhat weird class structure...
this could be the case, but there is no rule that say "don't do this it's evil" ;-)
Are you sure? My hope is that an in-depth search of the JDBC specification will actually say that "returning CallableStatement from a Connection#prepareStatement is evil and not allowed".
Maybe not with that exact wording. :)
But just looking at the API docs I can't find what I want to find, only:
http://java.sun.com/j2se/1.4.2/docs/api/java/sql/Connection.html#prepareStatement(java.lang.String,%20int,%20int)
That says that prepareStatement _must_ return instanceof PreparedStatement.
And: http://java.sun.com/j2se/1.4.2/docs/api/java/sql/CallableStatement.html
That says that CallableStatement extends PreparedStatement.
So in theory, just from reading the API docs, it looks like the driver is not evil...
As a german dogmatist I conclude your are lost ;-)
Maybe you could try to write a really small stand-alone JDBC test class and debug Connection#prepareStatement vs Connection#prepareCall and see if there is anything in the class structure that can be used to separate the two?
hmm, I don't like this. I think the assumption made in Platform.isCallableStatement is wrong, this is the problem not the driver implementation class (in next version of the driver tis can change....).
IMO it's a fault in the driver if it does this, but as you say: if the JDBC spec does not explicitly forbid this it is allowed and OJB have to face the fact that some drivers might or might not conform to the "de-factor" standard of not downcasting non-callable PreparedStatement to also implement CallableStatement.
BTW: is this really the default MaxDB driver behaviour? No special config?
yep, I don't use any driver settings.
Maybe Vadim has more input re. your suggested solution to read the info from the OJB descriptors instead?
Yep!
The more I think about this the more I'm convinced that this check is completely unnecessary, because OJB has to know when a stored procedure was used not the Statement. Maybe there is a design fault in StatementManager/StatementForClass classes.
regards Armin
Regards, Martin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
