ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From j-lists <jamisonli...@gmail.com>
Subject Re: Data type mismatch with queryForObject, on String property with String value!
Date Tue, 19 Feb 2008 09:09:32 GMT
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.2008 16: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.executeQueryWithCallback
> > (GeneralStatement.java:185)
> > at
> >
> com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.executeQueryForObject
> > (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.
>
>

Mime
View raw message