🚀 go-pugleaf

Hello,

I have a problem with JBoss 4.0.3sp1 running on Linux and talking to 
Interbase 7.5
via interclient driver.

When JBoss is started on Windows everything works perfectly well.
But when JBoss is started on Linux there are times while updating rows when
an error appears:

java.sql.SQLException: [interclient][interbase]arithmetic exception, numeric 
overflow, or string truncation
[interclient][interbase]Cannot transliterate character between character 
sets
 at interbase.interclient.Statement.remote_EXECUTE_UPDATE_STATEMENT(Unknown 
Source)
 at 
interbase.interclient.PreparedStatement.remote_EXECUTE_PREPARED_UPDATE_STATEMENT(Unknown 
Source)
 at interbase.interclient.PreparedStatement.executeUpdate(Unknown Source)
 at interbase.interclient.PreparedStatement.executeUpdate(Unknown Source)
 at 
org.jboss.resource.adapter.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:227)


Database is each time the same and set to use UNICODE_FSS

My interbase-ds.xml stored in $JBOSS_HOEM/server/default/deploy looks like:

//----------------------------------------------------------------------------------------------------------------------------------------------------

    ...

    <connection-url>jdbc:interbase://<path_to gdb_file></connection-url>

      <!-- The driver class -->
      <driver-class>interbase.interclient.Driver</driver-class>

      <!-- The login and password -->
      <user-name><correct_user></user-name>
      <password><correct_password></password>
      <charset>UTF8</charset>
      <config-property name="charSet" type="java.lang.String"  value="UTF8" 
/>
      <!--example of how to specify class that determines if exception means 
connection should be destroyed-->
      <!--exception-sorter-class-name>org.jboss.resource.adapter.jdbc.vendor.DummyExceptionSorter</exception-sorter-class-name-->
      <!-- this will be run before a managed connection is removed from the 
pool for use by a client-->
      <!--<check-valid-connection-sql>select * from 
something</check-valid-connection-sql> -->

      <!-- The minimum connections in a pool/sub-pool. Pools are lazily 
constructed on first use -->
      <min-pool-size>1</min-pool-size>

      <!-- The maximum connections in a pool/sub-pool -->
      <max-pool-size>2</max-pool-size>

      <!-- The time before an unused connection is destroyed -->
      <!-- NOTE: This is the check period. It will be destroyed somewhere 
between 1x and 2x this timeout after last use -->
      <!-- TEMPORARY FIX! - Disable idle connection removal, HSQLDB has a 
problem with not reaping threads on closed connections -->
      <idle-timeout-minutes>0</idle-timeout-minutes>
//----------------------------------------------------------------------------------------------------------------------------------------------------------------

Already have tried diffferent setting for charSet - nothing helped.

The strange thing is that sometimes exactly  the same method with exactly 
the same data invoked, of cource exeactly the same way - so sometimes it 
works and sometimes it doesn't. It was checked about 40 times till now.

I was checking maybe JBoss passes different representations of the same 
String to prepared statement
- it is not the case.

|In 99% it is not a problem of not valid character set set - there are cases 
when everything works ok and after a minute,
the problem appears again.

It seems that cases when problematic functionality works well occur just 
after, and some time after server restart.
Later the methods that worked well just after restart start to throw "Cannot 
transliterate ".... ecexption.

I suspect that maybe some Connections (the initial ones ) are created in a 
different way then the rest.
Probably because of the misconfiguration of database access form JBoss to 
Interbase - interclient does not catch the "UTF8" encoding ( tried already 
with "UTF-8" and "UNICODE-FSS" ).   But I am not sure it it is that way.


The strange thing is that on WIndows machines everytyhing is always ok. 
Maybe "default encoding of interclient matches default encoding under 
Windows ? ...


Anybody knows solution to this problem ??


Regards,

Incasmin