Elias Martenson wrote: > > Den Thu, 06 Feb 2003 16:21:22 +0100 skrev Zabach, Elke: > > > Elias Martenson wrote: > > > >> I'm getting an interesting error when doing a prepared > >> statement (but it > >> works when using non-prepared statements). > >> > >> Here's the table definition: > >> > >> create table foo (id fixed(20) primary key, x > >> fixed(20), y fixed(20)) > >> > >> create table bar (id fixed(20) primary key) > >> > >> Here's the query: > >> > >> select * from foo foo1 > >> where ((select o2.id from bar o2 where foo1.x = > >> o2.id) = ?) or > >> ((select m3.id from bar m3 where foo1.y > >> = m3.id) = ?) > >> > >> Don't mind the silliness of the query. It's was originally > >> much larger, > >> and auth-generated from an EJB container. I've reduced it > to make it > >> easier to analyse. > >> > >> When I run the above SQL through > >> Connection.prepareStatement() I'm getting > >> the following exception: > >> > >> Exception in thread "main" > >> com.sap.dbtech.jdbc.exceptions.DatabaseException: [21000]: > >> Message not available > >> > >> [ stack trace snipped ] > >> > >> at Foo.main(Foo.java:11) > >> > >> But when I run it through Statement.executeQuery() (and > >> replacing the "?" > >> characters by the number "2") I'm getting the expected result. > >> > >> Error 21000 is not even in the error messages list so I have > >> no idea in > >> which direction to look. > > > > 21000 is an internal error which should never be returned > to the user. > > Oops > > We will fix this problem within the next versions. > > A workaround should be to tell the (stupid) kernel which kind, > > i.e. of which datatype, the parameters are by surrounding them > > with a function working only on the corresponding datatype: > > ABS or FIXED for numbers for example, SUBSTR (?, 1) > > for character data and so on. > > I hope you will be able to change the statement although it > > is a somehow prepared one. > > > > Sorry for any inconveniences > > Thanks for the information. It's much appreciated. > > Since EJB-QL supports the ABS operator (which is converted to > an ABS in > the generated SQL statement) I was able to work around the > bug. I'm now > back on track. :-) > > I would like a small clarification: Are you saying that it's still an > error, but that the error message is wrong? > > If this is the case, what other workarounds are there? Adding the ABS > works sometimes, but not always. And Orion, which is the application > server I use, really loves to create subqueries in its automatically > generated SQL code.
Mhm, no it is no real error. It is a missing feature of the kernel to force the info of the datatype and length of the select-result to the parameter-checking. The first thing for the kernel is to result an error the user has a chance to find in the manual and to react accordingly. But the better thing (don't ask for the version it will be in) would be, of course, to provide this datatype-info internally to the parameter-checking. We will do what we can, but stack of work is growing a little bit to fast during the last weeks. Elke SAP Labs Berlin _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
