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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > 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 > [EMAIL PROTECTED] > 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" <[EMAIL PROTECTED]> 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. > >
