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