So, one more success...
I have taken a part of the backup SQL file which fills the table2014-12-10 10:23 GMT+01:00 Eric Svenson <esvenson74@xxxxxxxxxxxxxx>:
Regards, EricSHOW ALL shows English_United States.1252 for all lc_ settings (but I have tried it with German and C locale with same results)Value 123.345 can be read from pg_admin.INSERT INTO dev_my_settings(123, 'test', 'test', 'test', 123, 123.345);> The restore left you with two empty tables. What happens if you log into Postgres > via psql and then INSERT one set of values containing floats into say, >dev_my_settings?SUCCESS! This works OK!2014-12-08 22:57 GMT+01:00 Adrian Klaver <adrian.klaver@xxxxxxxxxxx>:On 12/08/2014 06:53 AM, Eric Svenson wrote:
Hi Adrian,
I try to get access to the non-VM machine, at the moment access is not
possible for me unfortunately.
You are right, there are more tables in the database which are restored
correctly but these tables do NOT contain float values. These two tables
are the only tables in the database which contain floats.
The errors occur with the first float in the table, the restore process
seems to terminate with that table and seems to continue with the next
table. The result are completely empty tables for dev_my_settings and
file_item.
There are float values in the table which can be viewed with pg_admin.
The table definitions for dev_my_settings and file_item contain lots of
BIGINTS, smallints and integers, and several double precision values.
All other tables do not contain any double precision values.
Alright a chance to think some more.
So:
The restore left you with two empty tables. What happens if you log into Postgres via psql and then INSERT one set of values containing floats into say, dev_my_settings?
While you are in psql, what does SHOW ALL display for the lc_* settings?
On the Windows server where the Postgres server is running what does SET show from the command line?
