Skip site navigation (1) Skip section navigation (2)

Re: [ODBC] catastrophic error

From: "Joel Fradkin" <jfradkin(at)wazagua(dot)com>
To: "'Marko Ristola'" <marko(dot)ristola(at)kolumbus(dot)fi>
Cc: "'Bricklen Anderson'" <BAnderson(at)PresiNET(dot)com>,<pgsql-odbc(at)postgresql(dot)org>, <pgsql-admin(at)postgresql(dot)org>
Subject: Re: [ODBC] catastrophic error
Date: 2005-05-13 12:34:44
Message-ID: 003b01c557b8$245d4b20$797ba8c0@jfradkin (view raw or flat)
Thread:
Lists: pgsql-adminpgsql-odbc
Thank you much I will give it a try and see how it goes appreciate all the
info.

About ASCII to Unicode conversion (if you have only Latin1 characters in 
the database):

Here is a receipt, how you can do a charset conversion from SQL_ASCII into
UNICODE on the Linux side:
(check these from manual pages first!):

1. Stop PostgreSQL and make a good backup!
"su - postgres" ; "pg_dumpall -D > everything-latin1.dump"
"file everything-latin1.dump" might tell you the charset.
Watch out for \345 style octal numbers, because iconv character 
converter won't see them.
PostgreSQL protects non-ascii characters that way at least in ASCII backups.

(The -D above makes the restore phase slow. I use it if I switch a 
PostgreSQL version,
because the rows are standard SQL sentences. Very portable.
The slowness can be resolved at least by filtering the
file with AWK and combining many inserts into a single transaction
(BEGIN,many inserts, COMMIT). )

cat everything-latin1.dump | iconv -f LATIN1 -t  UTF-8 > 
everything-utf8.dump
stop PostgreSQL.
remove the old database
Check PostgreSQL configuration files!
su - postgres
initdb with UTF-8.
su - postgres ; psql -f everything-utf8.dump template1

Please check the above phases, but that is approximately, how it goes.
Additional documentation: man pg_dumpall, man initdb, man createdb, man 
psql, man iconv

Database speed:
speed loader format is fastest on restore (pg_dumpall without -D).
Inserts within reasonable sized transactions are lots
of faster than inserts in autocommit mode (pg_dumpall with -D).


Good night.

Marko Ristola

Joel Fradkin wrote:

>The catastrophic error was the actual text sent from the IIS component
>error.
>
>SO I am not 100% sure what it means, I believe it is just mirroring back
>text from the dbserver when trying to connect and failing.
>
>I am guessing it is odbc and I am currently using the 7.4 version, but am
>looking for the best way to move from SQL_ASCHII to UNICODE (maybe a backup
>and restore using some kind of params? I hope?
>
>If not I guess I could alter my original program that read MSSQL to read
>from postgres and write it back to a Unicode database and see if the odbc
>drivers are ok (it originally blew up and that's how I ended up using
>SQL_ASCHII).
>
>Joel Fradkin
>
>What does a catastrophic error consist of? Do you mean your IIS servers
>could no longer connect to the db, and yet you _could_ connect to the db
via
>pgadmin? Yes the web interface gave that as the conection error string (my
>error routine just prints that to the screen)
>I would have thought that rebooting the IIS would have solved any
>connectivity issues (assuming that that is the error that you are getting).
>I've never used IIS, so I can't even guess about that. ODBC is a
>possibility, I suppose, and it certainly wouldn't hurt to try again on the
>ODBC list.
>
>
>Cheers,
>
>Bricklen
>
>  
>


In response to

pgsql-odbc by date

Next:From: Kille TmatDate: 2005-05-14 08:04:53
Subject: CrAz88Girz
Previous:From: Andreas PflugDate: 2005-05-13 11:00:05
Subject: Re: encoding

pgsql-admin by date

Next:From: Gourish SingbalDate: 2005-05-13 13:21:55
Subject: Re: Help with connections
Previous:From: Michael KichanovDate: 2005-05-13 09:11:18
Subject: Incremental backup

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group