Problem with Informix JDBC, MONEY and decimal separator in string literals

Question

I have problem with JDBC application that uses MONEY data type. When I insert into MONEY column:

insert into _money_test (amt) values ('123.45')

I got exception:

Character to numeric conversion error

The same SQL works from native Windows application using ODBC driver. I live in Poland and have Polish locale and in my country comma separates decimal part of number, so I tried:

insert into _money_test (amt) values ('123,45')

And it worked. I checked that in PreparedStatement I must use dot separator: 123.45. And of course I can use:

insert into _money_test (amt) values (123.45)

But some code is "general", it imports data from csv file and it was safe to put number into string literal.

How to force JDBC to use DBMONEY (or simply dot) in literals?

My workstation is WinXP. I have ODBC and JDBC Informix client in version 3.50 TC5/JC5. I have set DBMONEY to just dot:

DBMONEY=.

EDIT:

Test code in Jython:

import sys
import traceback
from java.sql import DriverManager
from java.lang import Class

Class.forName("com.informix.jdbc.IfxDriver")

QUERY = "insert into _money_test (amt) values ('123.45')"

def test_money(driver, db_url, usr, passwd):
    try:
        print("\n\n%s\n--------------" % (driver))
        db = DriverManager.getConnection(db_url, usr, passwd)
        c = db.createStatement()
        c.execute("delete from _money_test")
        c.execute(QUERY)
        rs = c.executeQuery("select amt from _money_test")
        while (rs.next()):
            print('[%s]' % (rs.getString(1)))
        rs.close()
        c.close()
        db.close()
    except:
        print("there were errors!")
        s = traceback.format_exc()
        sys.stderr.write("%s\n" % (s))



print(QUERY)
test_money("com.informix.jdbc.IfxDriver", 'jdbc:informix-sqli://169.0.1.225:9088/test:informixserver=ol_225;DB_LOCALE=pl_PL.CP1250;CLIENT_LOCALE=pl_PL.CP1250;charSet=CP1250', 'informix', 'passwd')
test_money("sun.jdbc.odbc.JdbcOdbcDriver", 'jdbc:odbc:test', 'informix', 'passwd')

Results when I run money literal with dot and comma:

C:\db_examples>jython ifx_jdbc_money.py
insert into _money_test (amt) values ('123,45')


com.informix.jdbc.IfxDriver
--------------
[123.45]


sun.jdbc.odbc.JdbcOdbcDriver
--------------
there were errors!
Traceback (most recent call last):
    File "ifx_jdbc_money.py", line 16, in test_money
        c.execute(QUERY)
SQLException: java.sql.SQLException: [Informix][Informix ODBC Driver][Informix]Character to numeric conversion error


C:\db_examples>jython ifx_jdbc_money.py
insert into _money_test (amt) values ('123.45')


com.informix.jdbc.IfxDriver
--------------
there were errors!
Traceback (most recent call last):
    File "ifx_jdbc_money.py", line 16, in test_money
        c.execute(QUERY)
SQLException: java.sql.SQLException: Character to numeric conversion error



sun.jdbc.odbc.JdbcOdbcDriver
--------------
[123.45]

Answer 1

The Informix JDBC data type mapping documentation says the following:

java.math.BigDecimal           MONEY(p,s)1

Thus, you need to use java.math.BigDecimal instead of java.lang.String to represent the value, PreparedStatement#setBigDecimal() to set the value and ResultSet#getBigDecimal() to get the value.

You can "convert" from String to BigDecimal by just passing it as constructor argument. The other way round can be done by calling the toString() method of BigDecimal.

Answer 2

I solved this problem by using PreparedStatement. I think that "Character to numeric conversion error" is a bug in Informix JDBC driver.

In other database I often use, PostgreSQL, there is no difference if I run query via native JDBC driver or via JDBC-ODBC bridge. I found that PostgreSQL do not accept numeric form 123.45. PostgreSQL accepts string literal with dot, but this dot is handled as a thousand separator. The only correctly accepted value is string literal where comma separates decimal part.

EDIT:

It can be solved by setting DBMONEY=. on server side, then all connections (ODBC, JDBC) will work with that setting.