ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tracey Annison" <tanni...@trisystems.co.uk>
Subject RE: Data type mismatch with queryForObject, on String property with String value!
Date Tue, 19 Feb 2008 08:58:59 GMT
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 - Enterprise Solution Division - IBM Business Partner
Prolifics Deutschland GmbH
Notkestr. 3, D-22607 Hamburg
phone +49 (0)40 890 667-70
fax    +49 (0)40 890 667-99
 <mailto:marc.heimann@prolifics.de> 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