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

--
_______________________________

This e-mail may be privileged and/or confidential, and the sender does
not waive any related rights and obligations. Any distribution, use or
copying of this e-mail or the information it contains by other than an
intended recipient is unauthorized. If you received this e-mail in
error, please advise me (by return e-mail or otherwise) immediately.
_______________________________


---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

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
>
>
>


---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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
>
>
>


---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)