ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Butler" <jeffgbut...@gmail.com>
Subject Re: Data type mismatch with queryForObject, on String property with String value!
Date Tue, 19 Feb 2008 20:06:00 GMT
This is a driver property - AFAIK it can't be configured per
table.  Probably the best thing to do is to fix the CCSID on the problem
tables on the AS/400 side.

Jeff Butler

On Feb 19, 2008 3:42 AM, Tracey Annison <tannison@trisystems.co.uk> wrote:

> Heya
>
> Thanks for that! It could be a problem for me setting it on the JDBC
> driver, though, as this is   perfectly OK for most of the AS/400 files -
> there's just a couple that have this different CCSID. Looks like I'd ned to
> configure it in iBatis, per file, which I don't see any info about so far...
>
> Cheers
> Tracey Annison
>
> -----Original Message-----
> From: j-lists [mailto:jamisonlists@gmail.com]
> Sent: 19 February 2008 09:10
> To: user-java@ibatis.apache.org
> Subject: Re: Data type mismatch with queryForObject, on String property
> with String value!
>
> I have encountered something similar to this before and I think there were
> 2 elements to the solution. The first was that the system default CCSID on
> the AS/400 was not set and I believe the second was that we could set a jdbc
> driver property in the toolkit driver to override it
> - or something like that. That's all I remember (beyond the fact that IBM
> themselves had no answer for us, we flailed around for 4 days before we
> figured it out through dumb luck).
> Thankfully I don't have to work with AS/400s anymore.
>
> On Feb 19, 2008 4:58 PM, Tracey Annison <tannison@trisystems.co.uk> wrote:
> >
> >
> > Well, it turned out to be nothing to do with the data type setup, in
> > the end...
> >
> > We had a similar problem with another file, and wrote code to return
> > data in a different way, which unexpectedly gave us hex instead of what
> we expected.
> > Turns out that both files had an unexpected CCSID, AKA codepage or
> > character set ID. So every field in this table was returning a hex
> > value twice the size we expected, thus causing all sorts of havoc!
> >
> > I hope we'll be able to change the CCSID on these files, but just in
> > case we can't, does anyone know how to configure Ibatis to expect a
> > particular CCSID on a given table? Googling isn't giving me anything...
> >
> > Cheer
> > Tracey Annison
> >
> >
> >
> >  ________________________________
> >  From: Marc.Heimann@prolifics.de [mailto:Marc.Heimann@prolifics.de]
> > Sent: 15 February 2008 15:37
> > To: user-java@ibatis.apache.org
> > Subject: Re: Data type mismatch with queryForObject, on String
> > property with String value!
> >
> >
> >
> >
> > If I  remember correctly we had the same problem in the past.
> > The error actually occured with the BigDecimal parameter but was
> > reported to happen elsewhere.
> > Try #departmentCode:DECIMAL# and see if it helps.
> >
> > Cheers
> > Marc Heimann
> > Software Engineer
> >
> > Prolifics Deutschland GmbH
> > Notkestr. 3, D-22607 Hamburg
> > phone +49 (0)40 890 667-70
> > fax    +49 (0)40 890 667-99
> > marc.heimann@prolifics.de
> > 2007 IBM Award Winner for Overall Technical Excellence SOA... Building
> > Future Business Solutions Today
> >
> > Handelsregister: Hamburg, HRB 89903
> > Geschäftsführer: Ulrich Frotscher
> >
> >
> > "Tracey Annison" <tannison@trisystems.co.uk> wrote on 15.02.200816:25:38:
> >
> > > Hiya
> > > We've been using ibatis with Java for ages, agaionst dtaabases on an
> > > AS/400, and have a standard way of coding that works fine for loads
> > > of files. But now I have some weird behaviour that I don't
> > > understand...
> > >
> >
> > > I have a TransactionCode.xml with a query in it like this :
> > >         <select id="getTransactionCodesCount"
> > >                                 parameterClass="java.util.HashMap"
> > >                                 resultClass="java.lang.Integer">
> > >                         <![CDATA[
> > >                 select count(*)
> > >         from $library$/XDXDFTC0
> > >         where TCCMCD = #companyCode#
> > >           and TCDPCD = #departmentCode#
> > >           and TCTCDE = #transactionCodename#
> > >                 ]]>
> > >     </select>
> > >
> >
> > > We're using that to see if there is a file entry :
> > >     public Boolean isTransactionCodeExtant(final String library,
> > >             final BigDecimal companyCode, final BigDecimal
> departmentCode,
> > >             final String transactionCode, final SqlMapClient
> sqlMapClient)
> > >             throws DAOException {
> > >         Map<String, Object> parameters = new HashMap<String,
> Object>();
> > >         parameters.put("library", library);
> > >         parameters.put("companyCode", companyCode);
> > >         parameters.put("departmentCode", departmentCode);
> > >         parameters.put("transactionCodename", transactionCode);
> > >         this.logger.debug("getTransactionCodesCount On parameters >
> > > "+parameters.toString());
> > >         Object result;
> > >         Integer occurrences;
> > >         try {
> > >                 this.logger
> > >                         .debug("getting Number of occurrences with
> > > transactionCode >" + transactionCode +"<");
> > >                 result = sqlMapClient.queryForObject(
> > >                         "getTransactionCodesCount", parameters);
> > >                 this.logger.debug("result = >" + String.valueOf
> (result));
> > >                 occurrences = (Integer) result;
> > >             this.logger.debug("Number of occurrences = >" +
> > > String.valueOf(occurrences));
> > >             if ((occurrences == null) || (occurrences == 0)) {
> > >                 return Boolean.FALSE;
> > >             }
> > >         } catch (SQLException exception) {
> > >             this.logger.debug("Ibatis DAO Exception", exception);
> > >             throw new DAOException(IbatisExceptionMessageConverter
> > >                     .extractUserExceptionMessage(exception));
> > >         }
> > >         return Boolean.TRUE;
> > >     }
> > >
> >
> > > I'm pasing it a String of "NCBONGTA" for library, BigDecimals
> > > holding 1 for companyCode and departmentCode, and a String of "PRM"
> > > for transactionCodename. I'm expecting to see a SQL statement in my
> > > log, and for it to come back with a sensible reply, just like it
> > > does on every other file, but instead I get a log like this :
> > >
> > > DEBUG 15-Feb-2008/14:30:13,196
> > > uk.co.xxxxx.TransactionCodeIbatisDAO.isTransactionCodeExtant():181 -
> > > getTransactionCodesCount On parameters > {transactionCodename=PRM,
> > > companyCode=1, library=NCBONGTA, departmentCode=1} DEBUG
> > > 15-Feb-2008/14:30:13,196
> > > uk.co.xxxxx.TransactionCodeIbatisDAO.isTransactionCodeExtant():186 -
> > > getting Number of occurrences with transactionCode >PRM< DEBUG
> > > 15-Feb-2008/14:30:13,618
> > > uk.co.xxxxx.TransactionCodeIbatisDAO.isTransactionCodeExtant():198 -
> > > Ibatis DAO Exception
> > > com.ibatis.common.jdbc.exception.NestedSQLException:
> > > --- The error occurred in /mappings/TransactionCode.xml.
> > > --- The error occurred while applying a parameter map.
> > > --- Check the getTransactionCodesCount-InlineParameterMap.
> > > --- Check the parameter mapping for the 'transactionCodename'
> property.
> > > --- Cause: java.sql.SQLException: Data type mismatch. (class
> > > java.lang.NumberFormatException)
> > > Caused by: java.sql.SQLException: Data type mismatch. (class
> > > java.lang.NumberFormatException)
> > > at
> > >
> > com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQue
> > ryWithCallback
> > > (GeneralStatement.java:185)
> > > at
> > >
> > com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQue
> > ryForObject
> > > (GeneralStatement.java:104)
> > >         at
> > > com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryForObject
> > > (SqlMapExecutorDelegate.java:561)
> > >         at
> > > com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryForObject
> > > (SqlMapExecutorDelegate.java:536)
> > >         at
> > > com.ibatis.sqlmap.engine.impl.SqlMapSessionImpl.queryForObject
> > > (SqlMapSessionImpl.java:93)
> > >         at
> > > com.ibatis.sqlmap.engine.impl.SqlMapClientImpl.queryForObject
> > > (SqlMapClientImpl.java:70)
> > >         at
> > > uk.co.xxxxx.TransactionCodeIbatisDAO.isTransactionCodeExtant
> > > (TransactionCodeIbatisDAO.java:188)
> > >
> >
> > > Which I don't understand at all! The inline parameter map is
> > > basically nonexistant - it's just a string. I haven't asked it tp do
> > > any number conversion on 'transactionCodename, 'cos its not a
> > > number! We do have a java file that maps to this file, but it echoes
> > > the property types exactly. I tried adding a definition for the java
> > > type and JDBC type in the #transactionCodename#, but it had no effect.
> > > Why is it throwing me a NumberFormatException on a field that's a
> > > String everywhere? On a file that looks perfectly normal and like
> > > all the others? I'm very confused...
> > > Any ideas for where I should look next would be most welcome!
> > > Cheers
> > > Tracey Annison
> > > --------------------------------------------------------------------
> > > -- The information in this email is confidential and may be legally
> > privileged.
> > > It is intended solely for the addressee. Access to this email by
> > > anyone else is unauthorised. If you are not the intended recipient,
> > > any disclosure, copying, distribution, or any action taken or
> > > omitted to be taken in reliance on it, is prohibited and may be
> unlawful.
> > > TriSystems Ltd. cannot accept liability for statements made which
> > > are
> > clearly
> > > the sender's own.
> > ----------------------------------------------------------------------
> > The information in this email is confidential and may be legally
> privileged.
> > It is intended solely for the addressee. Access to this email by
> > anyone else is unauthorised. If you are not the intended recipient,
> > any disclosure, copying, distribution, or any action taken or omitted
> > to be taken in reliance on it, is prohibited and may be unlawful.
> > TriSystems Ltd. cannot accept liability for statements made which are
> > clearly the sender's own.
> >
> >
>
>
>
> ----------------------------------------------------------------------
> The information in this email is confidential and may be legally
> privileged.
> It is intended solely for the addressee. Access to this email by
> anyone else is unauthorised. If you are not the intended recipient,
> any disclosure, copying, distribution, or any action taken or omitted
> to be taken in reliance on it, is prohibited and may be unlawful.
> TriSystems Ltd. cannot accept liability for statements made which are
> clearly
> the sender's own.
>
>
>

Mime
View raw message