I can't find working libdbi version

[John Ralls]

On Jan 28, 2011, at 6:56 AM, John Ralls wrote:

> 
> On Jan 28, 2011, at 4:26 AM, Christoph Holtermann wrote:
> 
>> Hello !
>>> Good catch. I've changed the way doubles are serialized in r20177; please give it a try.
>>> 
>>> Regards,
>>> John Ralls
>>> 
>> Thanks ! "make check" runs through without errors.
>> 
>> gnucash still doesn't like libdbi. Log says :
>> * 13:13:08  WARN <gnc.backend.dbi> [conn_test_dbi_library()] Test_DBI_Library: Double Failed     1,797692e+307 !=      1,000000e+00
>> 
>> Well these two values are surely not the same.
>> 
>> Mysql log is
>> 
>> /usr/sbin/mysqld, Version: 5.1.54-log (SUSE MySQL RPM). started with:
>> Tcp port: 3306  Unix socket: /var/run/mysql/mysql.sock
>> Time                 Id Command    Argument
>> 110128 13:15:29     4 Connect   christoph at localhost on gnucash
>>                   4 Query     CREATE TEMPORARY TABLE numtest ( test_int BIGINT, test_unsigned BIGINT, test_double FLOAT8 )
>>                   4 Query     INSERT INTO numtest VALUES (-9223372036854775807, 9223372036854775807, 1.7976921348623158e+307)
>>                   4 Query     SELECT * FROM numtest
>> 110128 13:15:32     4 Query     SHOW TABLES FROM gnucash LIKE 'gnclock'
>>                   4 Query     BEGIN
>>                   4 Query     SELECT * FROM gnclock WHERE Hostname = 'Holtermann' AND PID = '2705'
>>                   4 Query     ROLLBACK
>>                   4 Quit     
>> 110128 13:15:40     3 Quit     
>> 
>> IT looks like this time only the part BEFORE the decimal separator has been READ. Because the correct value has been stored as far as i understand
>> the log. ;-)
> 
> 
> I was afraid of that. It seems libdbi is using sprintf to parse the double from the database, and the input is getting localized. Since thousands separators are (ignored) noise, it's overflowing the double. Maybe I can retrieve the field as a string and use g_ascii_strtod() to parse it. If that works I'll have something for you to test tomorrow. (I'm not likely to get to it before your bedtime!)
> 

Well, it's a dreadful hack, but I've wrapped the dbi_result_get_double() calls with a setlocale() to make the LC_NUMERIC "C" and then put it back afterwards (r20189). It will have to do for 2.4.1. (dbi wouldn't let me have a string because the field is declared as a double.)

I guess I'll jump in to the mailing list discussion that Christoph started and see if I can influence them to allow direct access to the result string so that we can use the glib function to decode it... or to borrow that code themselves.

Regards,
John Ralls