Hello Gerardo, very interesting, thanks a lot.
Max > -----Ursprüngliche Nachricht----- > Von: Gerardo Arroyo [mailto:[EMAIL PROTECTED]] > Gesendet: Mittwoch, 4. Dezember 2002 17:17 > An: OJB Users List > Betreff: RE: OJB 0.9.8 and ORACLE > > > Hi Max, > > I found an open case at ORACLE Network. The main problem is the > specification of the setString method, and the Oracle guys > will not fix the > bug, because according they that is not a bug. Oh well, another people > recommend to use a "third-party" driver -if I found a fully > operational > driver I will let you know. > > Thanks, > Gerardo > > Bug No. 585844 > The JDBC API does not provide a way to differentiate CHARS > from VARCHAR2. > When setString is used we have chosen to map it to a > VARCHAR2, and as a > consequence the blank-padded and non-padded comparison > semantics for CHARs > don't work. Since this is an API restriction, we can't easily > fix it. What > can be done to fix it, is to add an Oracle Extension like > setChar(1,"one") > in which case JDBC will know that this type is s CHAR instead > of a VARCHAR2 > and the comparison semantics will work. I believe that since > this a JDBC > restriction, it should be treated as an enhancement request. > > *** 03/24/98 01:48 pm *** > I have a customer getting this error with 8.0.4. Is this > going add to any > future release? > > *** 04/01/98 06:21 pm *** (CHG: Asg->NEW OWNER) > *** 07/27/98 03:07 am *** (CHG: Sta->11) > *** 07/27/98 03:12 am *** > I have reviewed the API Specification (see section 8.3) and > it appears to me > that this is a bug, not an API restriction. I can supply a > test case if > required. My partner has developed a reverse engineering solution from > Informix 4GL to Java, and this single issue is causing them > major problems > in attempting to workaround it. > *** 03/21/99 07:08 am > *** (CHG: Asg->NEW OWNER) > *** 03/21/99 07:09 am > *** Updating versions, as I believe this bug has not been > fixed. Development > please respond. > *** 03/29/99 10:23 am > *** (CHG: Asg->NEW OWNER) > *** 03/29/99 10:23 am *** . > Btw, this is NOT a bug. Before i explain further, let me cut > & paste the > setString definition and specification from the Javasoft's page > ----------------------------------------------------------------- > /** > * Set a parameter to a Java String value. The driver converts this > * to a SQL VARCHAR or LONGVARCHAR value (depending on the arguments > * size relative to the driver's limits on VARCHARs) when it sends > * it to the database. * > * @param parameterIndex the first parameter is 1, the second is 2, ... > * @param x the parameter value */ > void setString(int parameterIndex, String x) throws > SQLException; > -------------------------------------------------------------- > --------- . . > > The spec. doesn't say anything about SQL CHAR columns and > hence i don't see > a reason that we MUST pad it to CHAR column length. . FOr > optimization > purpose, we don't get the column describe information before > we BIND and > hence we don't know whether its a SQL CHAR or SQL VAR CHAR > and hence we > can't pad it to its length. . . > However, we do acknowledge that right now there is no way from Oracle > PreparedStatement one can pad a CHAR column to its full length. We are > aware of this and working on this. We also need to get in touch with > Javasoft guys before we have the fix for this. Hopefully, we will have > something by the next patch set/release. . > > *** 04/27/99 09:25 am *** We are having discussions with Javasoft guys > regarding this. Hence, the fix may take little bit longer > than expected. > Sorry about that > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
