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 Wed, 20 Feb 2008 13:39:33 GMT
Thanks very much for your help! 

We're hoping we can change the CCSID... :) 


Cheers
Tracey Annison

-----Original Message-----
From: j-lists [mailto:jamisonlists@gmail.com] 
Sent: 20 February 2008 01:47
To: user-java@ibatis.apache.org
Subject: Re: Data type mismatch with queryForObject, on String property with String value!

If you can't fix the CCSID on the targets then maybe a long or BigInteger with the encoding
of the string into the bytes that it would be represented by in the target CCSID would do
the job? It would be a hack but I assume if you are on an AS/400 you aren't doing greenfield
development - if someone more important than you (or impossible to change) needs the different
CCSID I'm guessing your stuck with it.
You should be able to solve any problem with results with a type handler.

On Feb 20, 2008 4:06 AM, Jeff Butler <jeffgbutler@gmail.com> wrote:
> 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.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():1
> > > > 81 - getTransactionCodesCount On parameters > 
> > > > {transactionCodename=PRM, companyCode=1, library=NCBONGTA, 
> > > > departmentCode=1} DEBUG
> > > > 15-Feb-2008/14:30:13,196
> > > > uk.co.xxxxx.TransactionCodeIbatisDAO.isTransactionCodeExtant():1
> > > > 86 - getting Number of occurrences with transactionCode >PRM< 
> > > > DEBUG
> > > > 15-Feb-2008/14:30:13,618
> > > > uk.co.xxxxx.TransactionCodeIbatisDAO.isTransactionCodeExtant():1
> > > > 98 - 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.execut
> > > eQue
> > > ryWithCallback
> > > > (GeneralStatement.java:185)
> > > > at
> > > >
> > > com.ibatis.sqlmap.engine.mapping.statement.GeneralStatement.execut
> > > eQue
> > > ryForObject
> > > > (GeneralStatement.java:104)
> > > >         at
> > > > com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryForObj
> > > > ect
> > > > (SqlMapExecutorDelegate.java:561)
> > > >         at
> > > > com.ibatis.sqlmap.engine.impl.SqlMapExecutorDelegate.queryForObj
> > > > ect
> > > > (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.
> >
> >
> >
>
>



----------------------------------------------------------------------
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