[Oledb-dev] double precision error with pg linux server, but not with windows pg server

[Shachar Shemesh]

Julian Heeb wrote:
> Shachar Shemesh schrieb:
>   
>> Julian Heeb wrote:
>>   
>>     
>>> Hello
>>>
>>> Our acounting software can use the PostgreSQL OLE DB driver to access
>>> a postgreSQL database. With the pg server installed on windows,
>>> everything works fine.
>>>
>>> I moved now the database to a postgreSQL server on a linux server, but
>>> now every floating point number gets wrongly interpreted by the
>>> acounting software, either by replacing it with a 0 or a very large
>>> number (e.g. xxxE+308). Only the floating point numbers are affected,
>>> integer or characters are correct. pgAdmin shows even the fp numbers
>>> correctly, so I guess it has something to do with the pgoledb driver.
>>>
>>> Can someone give me a hint, how to solve the problem?
>>>     
>>>       
>> It's hard to give a precise answer. Let's try a couple of venues.
>>
>> First of all, what platform is the Linux server? Is that an Intel, or
>> something else?
>>   
>>     
> It is an ARM9 platform with Debian Etch (Linkstation Pro Fileserver with 
> Freelink).
>   
>> Also, what is the precise type of the floating point var on the server?
>> Can you give the SQL line that generated the table?
>>   
>>     
> The table has been generated by the following SQL line. The problem 
> occures at the double precision fields.
> I further observed that the values are correctly written into the table 
> by the acounting software (psql and pgAdmin show the right values in the 
> table), but are wrongly interpreted if they  are read from the db.
>
> CREATE TABLE fib_buchungen
>   
Can you please paste here the result of the following query:
select attname, atttypid, typname from pg_attribute left join pg_class
on attrelid=pg_class.oid left join pg_type on atttypid=pg_type.oid where
relname='fib_buchungen';

In particular, I'm interested in the lines that relate to the columns
that have the relevant type (for example, the "ankauffw" column).

I suspect that this may be a bug in Postgresql itself, and I need the
oid of the type in order to check this. Running on Debian Etch on Intel
on my machine, "double precision" is the type called "float8", which has
oid of 701. Please confirm this for me so I can move forward.

Thanks,
Shachar