LATIN1/9 conversion....

All
I have a recurrent error in my postgres 8.0.4 on redhat 9 (yes, I know
its old - first things first...) server. It only occurs from the
MSAccess/Windows clients I have, not from Java/JDBC or
pgAdminIII/Windows clients; hence the question here.

The log shows (anonymised) up to 6 times a second while a user is
active:

Feb 8 16:03:28 (server) postgres[8625]: [7-1] 2006-02-08
16:03:28 GMT (user)(database) ERROR: conversion between latin9 and
LATIN1 is not supported.


Now, I have added statement debugging to the log together with a "set
client_encoding to 'latin1'" in the ODBC driver, and got this:

Feb 8 15:48:18 (server) postgres[8277]: [6-1] 2006-02-08
15:48:18 GMT (user) (database) LOG: statement: select version()
Feb 8 15:48:18 (server) postgres[8277]: [7-1] 2006-02-08
15:48:18 GMT (user) (database) LOG: statement: set DateStyle to 'ISO'
Feb 8 15:48:18 (server) postgres[8277]: [8-1] 2006-02-08
15:48:18 GMT (user) (database) LOG: statement: set geqo to 'OFF'
Feb 8 15:48:18 (server) postgres[8277]: [9-1] 2006-02-08
15:48:18 GMT (user) (database) LOG: statement: set extra_float_digits
to 2
Feb 8 15:48:18 (server) postgres[8277]: [10-1] 2006-02-08
15:48:18 GMT (user) (database) LOG: statement: set client_encoding to
'latin1'
Feb 8 15:48:18 (server) postgres[8277]: [11-1] 2006-02-08
15:48:18 GMT (user) (database) LOG: statement: select oid from pg_type
where typname=3D'lo'
Feb 8 15:48:18 (server) postgres[8277]: [12-1] 2006-02-08
15:48:18 GMT (user) (database) LOG: statement: select
pg_client_encoding()
Feb 8 15:48:18 (server) postgres[8277]: [13-1] 2006-02-08
15:48:18 GMT (user) (database) LOG: statement: set client_encoding to
'latin9'
Feb 8 15:48:18 (server) postgres[8277]: [14-1] 2006-02-08
15:48:18 GMT (user) (database) ERROR: conversion between latin9 and
LATIN1 is not supported

You can clearly see my latin1 request followed shortly by the latin9. I
have examined the ODBC code and it looks like the culprit is a code page
of 1252.

Am I tracing this right? What do I do about? Suggestions, please!

Tim Clarke

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Re: LATIN1/9 conversion....

Hello,

I'm not much experienced in encoding.

> You can clearly see my latin1 request followed shortly by the latin9. I
> have examined the ODBC code and it looks like the culprit is a code page
> of 1252.

It could be interesting to see mylog output from Windows.
I don't understand well why it choose latin1 and then latin9.
Don't you specify 'set client_encoding to latin1' in DataSource
settings?
I'm new developer since 08.01 version so please be patient with me.

> Am I tracing this right? What do I do about? Suggestions, please!

You could use way of unicode driver. It use UTF-8 so no error occurs
with latin 1 x latin 9.
It means you may use "PostgreSQL Unicode" driver instead of
"PostgreSQL ANSI"

To other developers:
Another one user points to problems with win1252 -> Latin 9 mapping.
It seems to me that Latin 9 isn't right default choise for win1252.
What do you mean?

Regards,

Luf

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Re: LATIN1/9 conversion....

> -----Original Message-----
> From: Ludek Finstrle [mailto:luf@pzkagis.cz]=20
> Sent: 09 February 2006 15:21
> To: Tim Clarke
> Cc: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] LATIN1/9 conversion....
>=20
>=20
> Hello,
>=20
> I'm not much experienced in encoding.

No problem, Ludek (Luf?) - thanks for replying :-)

> > You can clearly see my latin1 request followed shortly by=20
> the latin9. I
> > have examined the ODBC code and it looks like the culprit=20
> is a code page
> > of 1252.
>=20
> It could be interesting to see mylog output from Windows.

I'm not running Postgres on Windows, just have some 'doze clients.

> I don't understand well why it choose latin1 and then latin9.

Seems to be hardcoded in the ODBC driver? File=20

> Don't you specify 'set client_encoding to latin1' in DataSource
> settings?

Yup - you can see it in the log I originally sent - ODBC driver then
sends the latin9 request!

> I'm new developer since 08.01 version so please be patient with me.

Patience? Always :-)

> > Am I tracing this right? What do I do about? Suggestions, please!
>=20
> You could use way of unicode driver. It use UTF-8 so no error occurs
> with latin 1 x latin 9.
> It means you may use "PostgreSQL Unicode" driver instead of
> "PostgreSQL ANSI"

We have found that the euro symbol and other accented characters are not
correctly stored if we do that. This database is currently coming across
nightly from an Oracle database so I'll be able to switch to Unicode
once that transition is complete. Real soon now.

> To other developers:
> Another one user points to problems with win1252 -> Latin 9 mapping.
> It seems to me that Latin 9 isn't right default choise for win1252.
> What do you mean?
>=20
> Regards,
>=20
> Luf
>=20

HTH
Tim Clarke

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Re: LATIN1/9 conversion....

> > > You can clearly see my latin1 request followed shortly by
> > the latin9. I
> > > have examined the ODBC code and it looks like the culprit
> > is a code page
> > > of 1252.
> >
> > It could be interesting to see mylog output from Windows.
>
> I'm not running Postgres on Windows, just have some 'doze clients.

:-) mylog is output from psqlODBC driver. You can enable it in ODBC
manager or by adding debug=1 in connection string (I don't know which
way do you use).

> > I don't understand well why it choose latin1 and then latin9.
>
> Seems to be hardcoded in the ODBC driver? File

It's strange for me that it's choosing twice.

> > Don't you specify 'set client_encoding to latin1' in DataSource
> > settings?
>
> Yup - you can see it in the log I originally sent - ODBC driver then
> sends the latin9 request!

This is the answer :-)
Hmmm. The driver doesn't care this one setting. It override it
automatically :-( Are you able to compile the driver yourself?
If so I can post you the hint how to disable automatic encoding
detection.

> > It means you may use "PostgreSQL Unicode" driver instead of
> > "PostgreSQL ANSI"
>
> We have found that the euro symbol and other accented characters are not
> correctly stored if we do that. This database is currently coming across
> nightly from an Oracle database so I'll be able to switch to Unicode
> once that transition is complete. Real soon now.

I'm not sure if we are both talking about same thing.
When you use LATIN1 PgSQL database and UNICODE psqlODBC driver there is
the problem?
I'm a little bit confused how it depend on "This database is currently
coming across nightly from an Oracle database". My English isn't
good. Maybe I only understand you bad.

What psqlODBC driver do you use? 08.00.0102 os some 08.01.XXXX?

Regards,

Luf

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Re: LATIN1/9 conversion....

This is a multi-part message in MIME format.

------_=_NextPart_001_01C62E32.E00F752E
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Luf.

> -----Original Message-----
> From: Ludek Finstrle [mailto:luf@pzkagis.cz]=20
> Sent: 10 February 2006 10:58
> To: Tim Clarke
> Cc: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] LATIN1/9 conversion....
>=20
> :-) mylog is output from psqlODBC driver. You can enable it in ODBC
> manager or by adding debug=3D1 in connection string (I don't know which
> way do you use).

Lol - don't use that often - forgot the default file name. Sample files
attached.

> It's strange for me that it's choosing twice.

I requested the latin1 setting manually in the ODBC Datasource (page 2)
"connect settings". Immediately after sending this the driver sends a
latin9 request.

> This is the answer :-)
> Hmmm. The driver doesn't care this one setting. It override it
> automatically :-( Are you able to compile the driver yourself?
> If so I can post you the hint how to disable automatic encoding
> detection.

I'm sure the driver is doing the setting for the right reason, its
probably just me that has some settings wrong that means its choosing
latin9 when we don't need it to.

> > > It means you may use "PostgreSQL Unicode" driver instead of
> > > "PostgreSQL ANSI"
> >=20
> > We have found that the euro symbol and other accented=20
> characters are not
> > correctly stored if we do that. This database is currently=20
> coming across
> > nightly from an Oracle database so I'll be able to switch to Unicode
> > once that transition is complete. Real soon now.
>=20
> I'm not sure if we are both talking about same thing.
> When you use LATIN1 PgSQL database and UNICODE psqlODBC=20
> driver there is
> the problem?

No, we tried a unicode database with the unicode ODBC psqldriver.
MSAccess couldn't write the correct characters to the database.

> I'm a little bit confused how it depend on "This database is currently
> coming across nightly from an Oracle database". My English isn't
> good. Maybe I only understand you bad.

We have a nightly script (based around the ora2pg project -
http://www.samse.fr/GPL/) that sucks our live Oracle database to the
developing Postgres replacement database. We have found that if the
postgres database is unicode, we corrupt the international characters
and euro symbols here, too.

> What psqlODBC driver do you use? 08.00.0102 os some 08.01.XXXX?

I have had this problem with evry driver from 08.01.01xx to the current
08.01.02

> Regards,
>=20
> Luf

Regards and thanks for your continuing attention.

Tim Clarke

------_=_NextPart_001_01C62E32.E00F752E
Content-Type: application/octet-stream;
name="psqlodbc_2224.log"
Content-Transfer-Encoding: base64
Content-Description: psqlodbc_2224.log
Content-Disposition: attachment;
filename="psqlodbc_2224.log"

Q09OTiBFUlJPUjogZnVuYz1QR0FQSV9HZXRDb25uZWN0T3B0aW9uLCBkZXNj
PSdmT3B0aW9uPTMwMDAyJywgZXJybnVtPTIwNSwgc3Fsc3RhdGU9LCBlcnJt
c2c9J1Vua25vd24gY29ubmVjdCBvcHRpb24gKEdldCknCiAgICAgICAgICAg
IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLQogICAgICAgICAgICBoZW52PTEyOTEyMTU1Miwg
Y29ubj0xMjkxMjE2MDgsIHN0YXR1cz0wLCBudW1fc3RtdHM9MTYKY29ubj0x
MjkxMjE2MDgsIFBHQVBJX0RyaXZlckNvbm5lY3QoIGluKT0nRFNOPXBncmVz
ZWFyY2g7VUlEPXRpbWM7UFdEPXh4eHh4eHh4O0RCUT1SRVNFQVJDSDtEQkE9
VztBUEE9VDtFWEM9RjtGRU49VDtRVE89VDtGUkM9MTA7RkRMPTEwO0xPQj1U
O1JTVD1UO0dERT1GO0ZSTD1UO0JBTT1JZkFsbFN1Y2Nlc3NmdWw7TVRTPUY7
TURJPUY7Q1NSPUY7RldDPUY7UEZDPTEwO1RMTz0wOycsIGZEcml2ZXJDb21w
bGV0aW9uPTAKRFNOIGluZm86IERTTj0ncGdyZXNlYXJjaCcsc2VydmVyPSdt
YW4xLm0xLm1hbmlmZXN0LmNvLnVrJyxwb3J0PSc1NDMyJyxkYmFzZT0ncmVz
ZWFyY2gnLHVzZXI9J3RpbWMnLHBhc3N3ZD0neHh4eHgnCiAgICAgICAgICBv
bmx5cmVhZD0nMCcsc2hvd29pZD0nMCcsZmFrZW9pZGluZGV4PScwJyxzaG93
c3lzdGFibGU9JzAnCiAgICAgICAgICBjb25uX3NldHRpbmdzPScnLGNvbm5f
ZW5jb2Rpbmc9J09USEVSJwogICAgICAgICAgdHJhbnNsYXRpb25fZGxsPScn
LHRyYW5zbGF0aW9uX29wdGlvbj0nJwo=

------_=_NextPart_001_01C62E32.E00F752E
Content-Type: application/octet-stream;
name="psqlodbc_3604.log"
Content-Transfer-Encoding: base64
Content-Description: psqlodbc_3604.log
Content-Disposition: attachment;
filename="psqlodbc_3604.log"

RFNOIGluZm86IERTTj0nUEdSZXNlYXJjaCcsc2VydmVyPSdtYW4xLm0xLm1h
bmlmZXN0LmNvLnVrJyxwb3J0PSc1NDMyJyxkYmFzZT0ncmVzZWFyY2gnLHVz
ZXI9J2FkbWluJyxwYXNzd2Q9J3h4eHh4JwogICAgICAgICAgb25seXJlYWQ9
JzAnLHNob3dvaWQ9JzAnLGZha2VvaWRpbmRleD0nMCcsc2hvd3N5c3RhYmxl
PScwJwogICAgICAgICAgY29ubl9zZXR0aW5ncz0nJyxjb25uX2VuY29kaW5n
PSdPVEhFUicKICAgICAgICAgIHRyYW5zbGF0aW9uX2RsbD0nJyx0cmFuc2xh
dGlvbl9vcHRpb249JycK

------_=_NextPart_001_01C62E32.E00F752E
Content-Type: application/octet-stream;
name="mylog_2224.log"
Content-Transfer-Encoding: base64
Content-Description: mylog_2224.log
Content-Disposition: attachment;
filename="mylog_2224.log"

WzI3MTJdZ2xvYmFscy5leHRyYV9zeXN0YWJsZV9wcmVmaXhlcyA9ICdkZF87
JwpbMjcxMl1bW1NRTEFsbG9jSGFuZGxlXV1bMjcxMl0qKioqIGluIFBHQVBJ
X0FsbG9jRW52ICoqIApbMjcxMl0qKiBleGl0IFBHQVBJX0FsbG9jRW52OiBw
aGVudiA9IDEyOTEyMTU1MiAqKgpbMjcxMl1bW1NRTFNldEVudkF0dHJdXSBh
dHQ9MjAwLDIKWzI3MTJdW1tTUUxBbGxvY0hhbmRsZV1dWzI3MTJdUEdBUElf
QWxsb2NDb25uZWN0OiBlbnRlcmluZy4uLgpbMjcxMl0qKioqIFBHQVBJX0Fs
bG9jQ29ubmVjdDogaGVudiA9IDEyOTEyMTU1MiwgY29ubiA9IDEyOTEyMTYw
OApbMjcxMl1FTl9hZGRfY29ubmVjdGlvbjogc2VsZiA9IDEyOTEyMTU1Miwg
Y29ubiA9IDEyOTEyMTYwOApbMjcxMl0gICAgICAgYWRkZWQgYXQgaSA9MCwg
Y29ubi0+aGVudiA9IDEyOTEyMTU1MiwgY29ubnNbaV0tPmhlbnYgPSAxMjkx
MjE1NTIKWzI3MTJdW1NRTEdldEluZm8oMzApXVsyNzEyXVBHQVBJX0dldElu
Zm86IGVudGVyaW5nLi4uZkluZm9UeXBlPTc3ClsyNzEyXVBHQVBJX0dldElu
Zm86IHA9JzAzLjAwJywgbGVuPTUsIHZhbHVlPTAsIGNiTWF4PTEyClsyNzEy
XVtbU1FMU2V0Q29ubmVjdEF0dHJdXSAxMDMKWzI3MTJdUEdBUElfU2V0Q29u
bmVjdEF0dHIgMTAzClsyNzEyXVBHQVBJX1NldENvbm5lY3RPcHRpb246IGVu
dGVyaW5nIGZPcHRpb24gPSAxMDMgdlBhcmFtID0gMjAKWzI3MTJdW1tTUUxH
ZXRDb25uZWN0QXR0cl1dIDMwMDAyClsyNzEyXVBHQVBJX0dldENvbm5lY3RB
dHRyIDMwMDAyClsyNzEyXVBHQVBJX0dldENvbm5lY3RPcHRpb246IGVudGVy
aW5nLi4uClsyNzEyXUNPTk4gRVJST1I6IGZ1bmM9UEdBUElfR2V0Q29ubmVj
dE9wdGlvbiwgZGVzYz0nZk9wdGlvbj0zMDAwMicsIGVycm51bT0yMDUsIHNx
bHN0YXRlPSwgZXJybXNnPSdVbmtub3duIGNvbm5lY3Qgb3B0aW9uIChHZXQp
JwpbMjcxMl1bW1NRTFNldENvbm5lY3RBdHRyXV0gMzAwMDIKWzI3MTJdUEdB
UElfU2V0Q29ubmVjdEF0dHIgMzAwMDIKWzI3MTJdUEdBUElfU2V0Q29ubmVj
dE9wdGlvbjogZW50ZXJpbmcgZk9wdGlvbiA9IDMwMDAyIHZQYXJhbSA9IDEy
ODc4NTA1NgpbMjcxMl1NaWNyb3NvZnQgSmV0ICEhISEKWzI3MTJdW1NRTERy
aXZlckNvbm5lY3RdWzI3MTJdUEdBUElfRHJpdmVyQ29ubmVjdDogZW50ZXJp
bmcuLi4KWzI3MTJdKioqKiBQR0FQSV9Ecml2ZXJDb25uZWN0OiBmRHJpdmVy
Q29tcGxldGlvbj0wLCBjb25uU3RySW49J0RTTj1wZ3Jlc2VhcmNoO1VJRD10
aW1jO1BXRD14eHh4eHh4eDtEQlE9UkVTRUFSQ0g7REJBPVc7QVBBPVQ7RVhD
PUY7RkVOPVQ7UVRPPVQ7RlJDPTEwO0ZETD0xMDtMT0I9VDtSU1Q9VDtHREU9
RjtGUkw9VDtCQU09SWZBbGxTdWNjZXNzZnVsO01UUz1GO01EST1GO0NTUj1G
O0ZXQz1GO1BGQz0xMDtUTE89MDsnClsyNzEyXW91cl9jb25uZWN0X3N0cmlu
ZyA9ICdEU049cGdyZXNlYXJjaDtVSUQ9dGltYztQV0Q9eHh4eHh4eHg7REJR
PVJFU0VBUkNIO0RCQT1XO0FQQT1UO0VYQz1GO0ZFTj1UO1FUTz1UO0ZSQz0x
MDtGREw9MTA7TE9CPVQ7UlNUPVQ7R0RFPUY7RlJMPVQ7QkFNPUlmQWxsU3Vj
Y2Vzc2Z1bDtNVFM9RjtNREk9RjtDU1I9RjtGV0M9RjtQRkM9MTA7VExPPTA7
JwpbMjcxMl1hdHRyaWJ1dGUgPSAnRFNOJywgdmFsdWUgPSAncGdyZXNlYXJj
aCcKWzI3MTJdY29weUF0dHJpYnV0ZXM6IERTTj0ncGdyZXNlYXJjaCcsc2Vy
dmVyPScnLGRiYXNlPScnLHVzZXI9JycscGFzc3dkPSd4eHh4eCcscG9ydD0n
Jyxzc2xtb2RlPScnLG9ubHlyZWFkPScnLGNvbm5fc2V0dGluZ3M9JycsZGlz
YWxsb3dfcHJlbWF0dXJlPS0xKQpbMjcxMl1hdHRyaWJ1dGUgPSAnVUlEJywg
dmFsdWUgPSAndGltYycKWzI3MTJdY29weUF0dHJpYnV0ZXM6IERTTj0ncGdy
ZXNlYXJjaCcsc2VydmVyPScnLGRiYXNlPScnLHVzZXI9J3RpbWMnLHBhc3N3
ZD0neHh4eHgnLHBvcnQ9Jycsc3NsbW9kZT0nJyxvbmx5cmVhZD0nJyxjb25u
X3NldHRpbmdzPScnLGRpc2FsbG93X3ByZW1hdHVyZT0tMSkKWzI3MTJdYXR0
cmlidXRlID0gJ1BXRCcsIHZhbHVlID0gJ3h4eHh4JwpbMjcxMl1jb3B5QXR0
cmlidXRlczogRFNOPSdwZ3Jlc2VhcmNoJyxzZXJ2ZXI9JycsZGJhc2U9Jycs
dXNlcj0ndGltYycscGFzc3dkPSd4eHh4eCcscG9ydD0nJyxzc2xtb2RlPScn
LG9ubHlyZWFkPScnLGNvbm5fc2V0dGluZ3M9JycsZGlzYWxsb3dfcHJlbWF0
dXJlPS0xKQpbMjcxMl1hdHRyaWJ1dGUgPSAnREJRJywgdmFsdWUgPSAnUkVT
RUFSQ0gnClsyNzEyXWNvcHlBdHRyaWJ1dGVzOiBEU049J3BncmVzZWFyY2gn
LHNlcnZlcj0nJyxkYmFzZT0nJyx1c2VyPSd0aW1jJyxwYXNzd2Q9J3h4eHh4
Jyxwb3J0PScnLHNzbG1vZGU9Jycsb25seXJlYWQ9JycsY29ubl9zZXR0aW5n
cz0nJyxkaXNhbGxvd19wcmVtYXR1cmU9LTEpClsyNzEyXWF0dHJpYnV0ZSA9
ICdEQkEnLCB2YWx1ZSA9ICdXJwpbMjcxMl1jb3B5QXR0cmlidXRlczogRFNO
PSdwZ3Jlc2VhcmNoJyxzZXJ2ZXI9JycsZGJhc2U9JycsdXNlcj0ndGltYycs
cGFzc3dkPSd4eHh4eCcscG9ydD0nJyxzc2xtb2RlPScnLG9ubHlyZWFkPScn
LGNvbm5fc2V0dGluZ3M9JycsZGlzYWxsb3dfcHJlbWF0dXJlPS0xKQpbMjcx
Ml1hdHRyaWJ1dGUgPSAnQVBBJywgdmFsdWUgPSAnVCcKWzI3MTJdY29weUF0
dHJpYnV0ZXM6IERTTj0ncGdyZXNlYXJjaCcsc2VydmVyPScnLGRiYXNlPScn
LHVzZXI9J3RpbWMnLHBhc3N3ZD0neHh4eHgnLHBvcnQ9Jycsc3NsbW9kZT0n
Jyxvbmx5cmVhZD0nJyxjb25uX3NldHRpbmdzPScnLGRpc2FsbG93X3ByZW1h
dHVyZT0tMSkKWzI3MTJdYXR0cmlidXRlID0gJ0VYQycsIHZhbHVlID0gJ0Yn
ClsyNzEyXWNvcHlBdHRyaWJ1dGVzOiBEU049J3BncmVzZWFyY2gnLHNlcnZl
cj0nJyxkYmFzZT0nJyx1c2VyPSd0aW1jJyxwYXNzd2Q9J3h4eHh4Jyxwb3J0
PScnLHNzbG1vZGU9Jycsb25seXJlYWQ9JycsY29ubl9zZXR0aW5ncz0nJyxk
aXNhbGxvd19wcmVtYXR1cmU9LTEpClsyNzEyXWF0dHJpYnV0ZSA9ICdGRU4n
LCB2YWx1ZSA9ICdUJwpbMjcxMl1jb3B5QXR0cmlidXRlczogRFNOPSdwZ3Jl
c2VhcmNoJyxzZXJ2ZXI9JycsZGJhc2U9JycsdXNlcj0ndGltYycscGFzc3dk
PSd4eHh4eCcscG9ydD0nJyxzc2xtb2RlPScnLG9ubHlyZWFkPScnLGNvbm5f
c2V0dGluZ3M9JycsZGlzYWxsb3dfcHJlbWF0dXJlPS0xKQpbMjcxMl1hdHRy
aWJ1dGUgPSAnUVRPJywgdmFsdWUgPSAnVCcKWzI3MTJdY29weUF0dHJpYnV0
ZXM6IERTTj0ncGdyZXNlYXJjaCcsc2VydmVyPScnLGRiYXNlPScnLHVzZXI9
J3RpbWMnLHBhc3N3ZD0neHh4eHgnLHBvcnQ9Jycsc3NsbW9kZT0nJyxvbmx5
cmVhZD0nJyxjb25uX3NldHRpbmdzPScnLGRpc2FsbG93X3ByZW1hdHVyZT0t
MSkKWzI3MTJdYXR0cmlidXRlID0gJ0ZSQycsIHZhbHVlID0gJzEwJwpbMjcx
Ml1jb3B5QXR0cmlidXRlczogRFNOPSdwZ3Jlc2VhcmNoJyxzZXJ2ZXI9Jycs
ZGJhc2U9JycsdXNlcj0ndGltYycscGFzc3dkPSd4eHh4eCcscG9ydD0nJyxz
c2xtb2RlPScnLG9ubHlyZWFkPScnLGNvbm5fc2V0dGluZ3M9JycsZGlzYWxs
b3dfcHJlbWF0dXJlPS0xKQpbMjcxMl1hdHRyaWJ1dGUgPSAnRkRMJywgdmFs
dWUgPSAnMTAnClsyNzEyXWNvcHlBdHRyaWJ1dGVzOiBEU049J3BncmVzZWFy
Y2gnLHNlcnZlcj0nJyxkYmFzZT0nJyx1c2VyPSd0aW1jJyxwYXNzd2Q9J3h4
eHh4Jyxwb3J0PScnLHNzbG1vZGU9Jycsb25seXJlYWQ9JycsY29ubl9zZXR0
aW5ncz0nJyxkaXNhbGxvd19wcmVtYXR1cmU9LTEpClsyNzEyXWF0dHJpYnV0
ZSA9ICdMT0InLCB2YWx1ZSA9ICdUJwpbMjcxMl1jb3B5QXR0cmlidXRlczog
RFNOPSdwZ3Jlc2VhcmNoJyxzZXJ2ZXI9JycsZGJhc2U9JycsdXNlcj0ndGlt
YycscGFzc3dkPSd4eHh4eCcscG9ydD0nJyxzc2xtb2RlPScnLG9ubHlyZWFk
PScnLGNvbm5fc2V0dGluZ3M9JycsZGlzYWxsb3dfcHJlbWF0dXJlPS0xKQpb
MjcxMl1hdHRyaWJ1dGUgPSAnUlNUJywgdmFsdWUgPSAnVCcKWzI3MTJdY29w
eUF0dHJpYnV0ZXM6IERTTj0ncGdyZXNlYXJjaCcsc2VydmVyPScnLGRiYXNl
PScnLHVzZXI9J3RpbWMnLHBhc3N3ZD0neHh4eHgnLHBvcnQ9Jycsc3NsbW9k
ZT0nJyxvbmx5cmVhZD0nJyxjb25uX3NldHRpbmdzPScnLGRpc2FsbG93X3By
ZW1hdHVyZT0tMSkKWzI3MTJdYXR0cmlidXRlID0gJ0dERScsIHZhbHVlID0g
J0YnClsyNzEyXWNvcHlBdHRyaWJ1dGVzOiBEU049J3BncmVzZWFyY2gnLHNl
cnZlcj0nJyxkYmFzZT0nJyx1c2VyPSd0aW1jJyxwYXNzd2Q9J3h4eHh4Jyxw
b3J0PScnLHNzbG1vZGU9Jycsb25seXJlYWQ9JycsY29ubl9zZXR0aW5ncz0n
JyxkaXNhbGxvd19wcmVtYXR1cmU9LTEpClsyNzEyXWF0dHJpYnV0ZSA9ICdG
UkwnLCB2YWx1ZSA9ICdUJwpbMjcxMl1jb3B5QXR0cmlidXRlczogRFNOPSdw
Z3Jlc2VhcmNoJyxzZXJ2ZXI9JycsZGJhc2U9JycsdXNlcj0ndGltYycscGFz
c3dkPSd4eHh4eCcscG9ydD0nJyxzc2xtb2RlPScnLG9ubHlyZWFkPScnLGNv
bm5fc2V0dGluZ3M9JycsZGlzYWxsb3dfcHJlbWF0dXJlPS0xKQpbMjcxMl1h
dHRyaWJ1dGUgPSAnQkFNJywgdmFsdWUgPSAnSWZBbGxTdWNjZXNzZnVsJwpb
MjcxMl1jb3B5QXR0cmlidXRlczogRFNOPSdwZ3Jlc2VhcmNoJyxzZXJ2ZXI9
JycsZGJhc2U9JycsdXNlcj0ndGltYycscGFzc3dkPSd4eHh4eCcscG9ydD0n
Jyxzc2xtb2RlPScnLG9ubHlyZWFkPScnLGNvbm5fc2V0dGluZ3M9JycsZGlz
YWxsb3dfcHJlbWF0dXJlPS0xKQpbMjcxMl1hdHRyaWJ1dGUgPSAnTVRTJywg
dmFsdWUgPSAnRicKWzI3MTJdY29weUF0dHJpYnV0ZXM6IERTTj0ncGdyZXNl
YXJjaCcsc2VydmVyPScnLGRiYXNlPScnLHVzZXI9J3RpbWMnLHBhc3N3ZD0n
eHh4eHgnLHBvcnQ9Jycsc3NsbW9kZT0nJyxvbmx5cmVhZD0nJyxjb25uX3Nl
dHRpbmdzPScnLGRpc2FsbG93X3ByZW1hdHVyZT0tMSkKWzI3MTJdYXR0cmli
dXRlID0gJ01ESScsIHZhbHVlID0gJ0YnClsyNzEyXWNvcHlBdHRyaWJ1dGVz
OiBEU049J3BncmVzZWFyY2gnLHNlcnZlcj0nJyxkYmFzZT0nJyx1c2VyPSd0
aW1jJyxwYXNzd2Q9J3h4eHh4Jyxwb3J0PScnLHNzbG1vZGU9Jycsb25seXJl
YWQ9JycsY29ubl9zZXR0aW5ncz0nJyxkaXNhbGxvd19wcmVtYXR1cmU9LTEp
ClsyNzEyXWF0dHJpYnV0ZSA9ICdDU1InLCB2YWx1ZSA9ICdGJwpbMjcxMl1j
b3B5QXR0cmlidXRlczogRFNOPSdwZ3Jlc2VhcmNoJyxzZXJ2ZXI9JycsZGJh
c2U9JycsdXNlcj0ndGltYycscGFzc3dkPSd4eHh4eCcscG9ydD0nJyxzc2xt
b2RlPScnLG9ubHlyZWFkPScnLGNvbm5fc2V0dGluZ3M9JycsZGlzYWxsb3df
cHJlbWF0dXJlPS0xKQpbMjcxMl1hdHRyaWJ1dGUgPSAnRldDJywgdmFsdWUg
PSAnRicKWzI3MTJdY29weUF0dHJpYnV0ZXM6IERTTj0ncGdyZXNlYXJjaCcs
c2VydmVyPScnLGRiYXNlPScnLHVzZXI9J3RpbWMnLHBhc3N3ZD0neHh4eHgn
LHBvcnQ9Jycsc3NsbW9kZT0nJyxvbmx5cmVhZD0nJyxjb25uX3NldHRpbmdz
PScnLGRpc2FsbG93X3ByZW1hdHVyZT0tMSkKWzI3MTJdYXR0cmlidXRlID0g
J1BGQycsIHZhbHVlID0gJzEwJwpbMjcxMl1jb3B5QXR0cmlidXRlczogRFNO
PSdwZ3Jlc2VhcmNoJyxzZXJ2ZXI9JycsZGJhc2U9JycsdXNlcj0ndGltYycs
cGFzc3dkPSd4eHh4eCcscG9ydD0nJyxzc2xtb2RlPScnLG9ubHlyZWFkPScn
LGNvbm5fc2V0dGluZ3M9JycsZGlzYWxsb3dfcHJlbWF0dXJlPS0xKQpbMjcx
Ml1hdHRyaWJ1dGUgPSAnVExPJywgdmFsdWUgPSAnMCcKWzI3MTJdY29weUF0
dHJpYnV0ZXM6IERTTj0ncGdyZXNlYXJjaCcsc2VydmVyPScnLGRiYXNlPScn
LHVzZXI9J3RpbWMnLHBhc3N3ZD0neHh4eHgnLHBvcnQ9Jycsc3NsbW9kZT0n
Jyxvbmx5cmVhZD0nJyxjb25uX3NldHRpbmdzPScnLGRpc2FsbG93X3ByZW1h
dHVyZT0tMSkKWzI3MTJdZ2xvYmFscy5leHRyYV9zeXN0YWJsZV9wcmVmaXhl
cyA9ICdkZF87JwpbMjcxMl1nbG9iYWxzLmV4dHJhX3N5c3RhYmxlX3ByZWZp
eGVzID0gJ2RkXzsnClsyNzEyXW91cl9jb25uZWN0X3N0cmluZyA9ICdEU049
cGdyZXNlYXJjaDtVSUQ9dGltYztQV0Q9eHh4eHh4eHg7REJRPVJFU0VBUkNI
O0RCQT1XO0FQQT1UO0VYQz1GO0ZFTj1UO1FUTz1UO0ZSQz0xMDtGREw9MTA7
TE9CPVQ7UlNUPVQ7R0RFPUY7RlJMPVQ7QkFNPUlmQWxsU3VjY2Vzc2Z1bDtN
VFM9RjtNREk9RjtDU1I9RjtGV0M9RjtQRkM9MTA7VExPPTA7JwpbMjcxMl1h
dHRyaWJ1dGUgPSAnRFNOJywgdmFsdWUgPSAncGdyZXNlYXJjaCcKWzI3MTJd
Q29weUNvbW1vbkF0dHJpYnV0ZXM6IEE3PTEwMDtBOD04MTkyO0E5PTA7QjA9
NDAwMDtCMT04MTkwO0IyPTA7QjM9MDtCND0xO0I1PTE7QjY9MDtCNz0xO0I4
PTA7Qjk9MTtDMD0wO0MxPTA7QzI9ZGRfO1syNzEyXWF0dHJpYnV0ZSA9ICdV
SUQnLCB2YWx1ZSA9ICd0aW1jJwpbMjcxMl1Db3B5Q29tbW9uQXR0cmlidXRl
czogQTc9MTAwO0E4PTgxOTI7QTk9MDtCMD00MDAwO0IxPTgxOTA7QjI9MDtC
Mz0wO0I0PTE7QjU9MTtCNj0wO0I3PTE7Qjg9MDtCOT0xO0MwPTA7QzE9MDtD
Mj1kZF87WzI3MTJdYXR0cmlidXRlID0gJ1BXRCcsIHZhbHVlID0gJ3h4eHh4
JwpbMjcxMl1Db3B5Q29tbW9uQXR0cmlidXRlczogQTc9MTAwO0E4PTgxOTI7
QTk9MDtCMD00MDAwO0IxPTgxOTA7QjI9MDtCMz0wO0I0PTE7QjU9MTtCNj0w
O0I3PTE7Qjg9MDtCOT0xO0MwPTA7QzE9MDtDMj1kZF87WzI3MTJdYXR0cmli
dXRlID0gJ0RCUScsIHZhbHVlID0gJ1JFU0VBUkNIJwpbMjcxMl1Db3B5Q29t
bW9uQXR0cmlidXRlczogQTc9MTAwO0E4PTgxOTI7QTk9MDtCMD00MDAwO0Ix
PTgxOTA7QjI9MDtCMz0wO0I0PTE7QjU9MTtCNj0wO0I3PTE7Qjg9MDtCOT0x
O0MwPTA7QzE9MDtDMj1kZF87WzI3MTJdYXR0cmlidXRlID0gJ0RCQScsIHZh
bHVlID0gJ1cnClsyNzEyXUNvcHlDb21tb25BdHRyaWJ1dGVzOiBBNz0xMDA7
QTg9ODE5MjtBOT0wO0IwPTQwMDA7QjE9ODE5MDtCMj0wO0IzPTA7QjQ9MTtC
NT0xO0I2PTA7Qjc9MTtCOD0wO0I5PTE7QzA9MDtDMT0wO0MyPWRkXztbMjcx
Ml1hdHRyaWJ1dGUgPSAnQVBBJywgdmFsdWUgPSAnVCcKWzI3MTJdQ29weUNv
bW1vbkF0dHJpYnV0ZXM6IEE3PTEwMDtBOD04MTkyO0E5PTA7QjA9NDAwMDtC
MT04MTkwO0IyPTA7QjM9MDtCND0xO0I1PTE7QjY9MDtCNz0xO0I4PTA7Qjk9
MTtDMD0wO0MxPTA7QzI9ZGRfO1syNzEyXWF0dHJpYnV0ZSA9ICdFWEMnLCB2
YWx1ZSA9ICdGJwpbMjcxMl1Db3B5Q29tbW9uQXR0cmlidXRlczogQTc9MTAw
O0E4PTgxOTI7QTk9MDtCMD00MDAwO0IxPTgxOTA7QjI9MDtCMz0wO0I0PTE7
QjU9MTtCNj0wO0I3PTE7Qjg9MDtCOT0xO0MwPTA7QzE9MDtDMj1kZF87WzI3
MTJdYXR0cmlidXRlID0gJ0ZFTicsIHZhbHVlID0gJ1QnClsyNzEyXUNvcHlD
b21tb25BdHRyaWJ1dGVzOiBBNz0xMDA7QTg9ODE5MjtBOT0wO0IwPTQwMDA7
QjE9ODE5MDtCMj0wO0IzPTA7QjQ9MTtCNT0xO0I2PTA7Qjc9MTtCOD0wO0I5
PTE7QzA9MDtDMT0wO0MyPWRkXztbMjcxMl1hdHRyaWJ1dGUgPSAnUVRPJywg
dmFsdWUgPSAnVCcKWzI3MTJdQ29weUNvbW1vbkF0dHJpYnV0ZXM6IEE3PTEw
MDtBOD04MTkyO0E5PTA7QjA9NDAwMDtCMT04MTkwO0IyPTA7QjM9MDtCND0x
O0I1PTE7QjY9MDtCNz0xO0I4PTA7Qjk9MTtDMD0wO0MxPTA7QzI9ZGRfO1sy
NzEyXWF0dHJpYnV0ZSA9ICdGUkMnLCB2YWx1ZSA9ICcxMCcKWzI3MTJdQ29w
eUNvbW1vbkF0dHJpYnV0ZXM6IEE3PTEwMDtBOD04MTkyO0E5PTA7QjA9NDAw
MDtCMT04MTkwO0IyPTA7QjM9MDtCND0xO0I1PTE7QjY9MDtCNz0xO0I4PTA7
Qjk9MTtDMD0wO0MxPTA7QzI9ZGRfO1syNzEyXWF0dHJpYnV0ZSA9ICdGREwn
LCB2YWx1ZSA9ICcxMCcKWzI3MTJdQ29weUNvbW1vbkF0dHJpYnV0ZXM6IEE3
PTEwMDtBOD04MTkyO0E5PTA7QjA9NDAwMDtCMT04MTkwO0IyPTA7QjM9MDtC
ND0xO0I1PTE7QjY9MDtCNz0xO0I4PTA7Qjk9MTtDMD0wO0MxPTA7QzI9ZGRf
O1syNzEyXWF0dHJpYnV0ZSA9ICdMT0InLCB2YWx1ZSA9ICdUJwpbMjcxMl1D
b3B5Q29tbW9uQXR0cmlidXRlczogQTc9MTAwO0E4PTgxOTI7QTk9MDtCMD00
MDAwO0IxPTgxOTA7QjI9MDtCMz0wO0I0PTE7QjU9MTtCNj0wO0I3PTE7Qjg9
MDtCOT0xO0MwPTA7QzE9MDtDMj1kZF87WzI3MTJdYXR0cmlidXRlID0gJ1JT
VCcsIHZhbHVlID0gJ1QnClsyNzEyXUNvcHlDb21tb25BdHRyaWJ1dGVzOiBB
Nz0xMDA7QTg9ODE5MjtBOT0wO0IwPTQwMDA7QjE9ODE5MDtCMj0wO0IzPTA7
QjQ9MTtCNT0xO0I2PTA7Qjc9MTtCOD0wO0I5PTE7QzA9MDtDMT0wO0MyPWRk
XztbMjcxMl1hdHRyaWJ1dGUgPSAnR0RFJywgdmFsdWUgPSAnRicKWzI3MTJd
Q29weUNvbW1vbkF0dHJpYnV0ZXM6IEE3PTEwMDtBOD04MTkyO0E5PTA7QjA9
NDAwMDtCMT04MTkwO0IyPTA7QjM9MDtCND0xO0I1PTE7QjY9MDtCNz0xO0I4
PTA7Qjk9MTtDMD0wO0MxPTA7QzI9ZGRfO1syNzEyXWF0dHJpYnV0ZSA9ICdG
UkwnLCB2YWx1ZSA9ICdUJwpbMjcxMl1Db3B5Q29tbW9uQXR0cmlidXRlczog
QTc9MTAwO0E4PTgxOTI7QTk9MDtCMD00MDAwO0IxPTgxOTA7QjI9MDtCMz0w
O0I0PTE7QjU9MTtCNj0wO0I3PTE7Qjg9MDtCOT0xO0MwPTA7QzE9MDtDMj1k
ZF87WzI3MTJdYXR0cmlidXRlID0gJ0JBTScsIHZhbHVlID0gJ0lmQWxsU3Vj
Y2Vzc2Z1bCcKWzI3MTJdQ29weUNvbW1vbkF0dHJpYnV0ZXM6IEE3PTEwMDtB
OD04MTkyO0E5PTA7QjA9NDAwMDtCMT04MTkwO0IyPTA7QjM9MDtCND0xO0I1
PTE7QjY9MDtCNz0xO0I4PTA7Qjk9MTtDMD0wO0MxPTA7QzI9ZGRfO1syNzEy
XWF0dHJpYnV0ZSA9ICdNVFMnLCB2YWx1ZSA9ICdGJwpbMjcxMl1Db3B5Q29t
bW9uQXR0cmlidXRlczogQTc9MTAwO0E4PTgxOTI7QTk9MDtCMD00MDAwO0Ix
PTgxOTA7QjI9MDtCMz0wO0I0PTE7QjU9MTtCNj0wO0I3PTE7Qjg9MDtCOT0x
O0MwPTA7QzE9MDtDMj1kZF87WzI3MTJdYXR0cmlidXRlID0gJ01ESScsIHZh
bHVlID0gJ0YnClsyNzEyXUNvcHlDb21tb25BdHRyaWJ1dGVzOiBBNz0xMDA7
QTg9ODE5MjtBOT0wO0IwPTQwMDA7QjE9ODE5MDtCMj0wO0IzPTA7QjQ9MTtC
NT0xO0I2PTA7Qjc9MTtCOD0wO0I5PTE7QzA9MDtDMT0wO0MyPWRkXztbMjcx
Ml1hdHRyaWJ1dGUgPSAnQ1NSJywgdmFsdWUgPSAnRicKWzI3MTJdQ29weUNv
bW1vbkF0dHJpYnV0ZXM6IEE3PTEwMDtBOD04MTkyO0E5PTA7QjA9NDAwMDtC
MT04MTkwO0IyPTA7QjM9MDtCND0xO0I1PTE7QjY9MDtCNz0xO0I4PTA7Qjk9
MTtDMD0wO0MxPTA7QzI9ZGRfO1syNzEyXWF0dHJpYnV0ZSA9ICdGV0MnLCB2
YWx1ZSA9ICdGJwpbMjcxMl1Db3B5Q29tbW9uQXR0cmlidXRlczogQTc9MTAw
O0E4PTgxOTI7QTk9MDtCMD00MDAwO0IxPTgxOTA7QjI9MDtCMz0wO0I0PTE7
QjU9MTtCNj0wO0I3PTE7Qjg9MDtCOT0xO0MwPTA7QzE9MDtDMj1kZF87WzI3
MTJdYXR0cmlidXRlID0gJ1BGQycsIHZhbHVlID0gJzEwJwpbMjcxMl1Db3B5
Q29tbW9uQXR0cmlidXRlczogQTc9MTAwO0E4PTgxOTI7QTk9MDtCMD00MDAw
O0IxPTgxOTA7QjI9MDtCMz0wO0I0PTE7QjU9MTtCNj0wO0I3PTE7Qjg9MDtC
OT0xO0MwPTA7QzE9MDtDMj1kZF87WzI3MTJdYXR0cmlidXRlID0gJ1RMTycs
IHZhbHVlID0gJzAnClsyNzEyXUNvcHlDb21tb25BdHRyaWJ1dGVzOiBBNz0x
MDA7QTg9ODE5MjtBOT0wO0IwPTQwMDA7QjE9ODE5MDtCMj0wO0IzPTA7QjQ9
MTtCNT0xO0I2PTA7Qjc9MTtCOD0wO0I5PTE7QzA9MDtDMT0wO0MyPWRkXztb
MjcxMl1QR0FQSV9EaXNjb25uZWN0OiBhYm91dCB0byBDQ19jbGVhbnVwClsy
NzEyXWluIENDX0NsZWFudXAsIHNlbGY9MTI5MTIxNjA4ClsyNzEyXWFmdGVy
IENDX2Fib3J0ClsyNzEyXWVudGVyaW5nIFBHQ09OTl9EZXN0cnVjdG9yIApb
MjcxMl1leGl0aW5nIFBHQ09OTl9EZXN0cnVjdG9yIApbMjcxMl1hZnRlciBM
SUJQUSBkZXN0cnVjdG9yClsyNzEyXWV4aXQgQ0NfQ2xlYW51cApbMjcxMl1Q
R0FQSV9EaXNjb25uZWN0OiBkb25lIENDX2NsZWFudXAKWzI3MTJdUEdBUElf
RGlzY29ubmVjdDogcmV0dXJuaW5nLi4uClsyNzEyXVtbU1FMRnJlZUhhbmRs
ZV1dWzI3MTJdUEdBUElfRnJlZUNvbm5lY3Q6IGVudGVyaW5nLi4uClsyNzEy
XSoqKiogaW4gUEdBUElfRnJlZUNvbm5lY3Q6IGhkYmM9MTI5MTIxNjA4Clsy
NzEyXWVudGVyIENDX0Rlc3RydWN0b3IsIHNlbGY9MTI5MTIxNjA4ClsyNzEy
XWluIENDX0NsZWFudXAsIHNlbGY9MTI5MTIxNjA4ClsyNzEyXWFmdGVyIExJ
QlBRIGRlc3RydWN0b3IKWzI3MTJdZXhpdCBDQ19DbGVhbnVwClsyNzEyXWFm
dGVyIENDX0NsZWFudXAKWzI3MTJdYWZ0ZXIgZnJlZSBzdGF0ZW1lbnQgaG9s
ZGVycwpbMjcxMl1leGl0IENDX0Rlc3RydWN0b3IKWzI3MTJdUEdBUElfRnJl
ZUNvbm5lY3Q6IHJldHVybmluZy4uLgpbMjcxMl1bW1NRTEZyZWVIYW5kbGVd
XVsyNzEyXSoqKiogaW4gUEdBUElfRnJlZUVudjogZW52ID0gMTI5MTIxNTUy
ICoqIApbMjcxMl1pbiBFTl9EZXN0cnVjdG9yLCBzZWxmPTEyOTEyMTU1Mgpb
MjcxMl1leGl0IEVOX0Rlc3RydWN0b3I6IHJ2ID0gMQpbMjcxMl0gICBvawo=

------_=_NextPart_001_01C62E32.E00F752E
Content-Type: application/octet-stream;
name="mylog_3604.log"
Content-Transfer-Encoding: base64
Content-Description: mylog_3604.log
Content-Disposition: attachment;
filename="mylog_3604.log"

WzM3MDBdZ2xvYmFscy5leHRyYV9zeXN0YWJsZV9wcmVmaXhlcyA9ICdkZF87
JwpbMzcwMF1hc3pLZXk9J0RTTicsIHZhbHVlPSdQR1Jlc2VhcmNoJwpbMzcw
MF1jb3B5QXR0cmlidXRlczogRFNOPSdQR1Jlc2VhcmNoJyxzZXJ2ZXI9Jycs
ZGJhc2U9JycsdXNlcj0nJyxwYXNzd2Q9J3h4eHh4Jyxwb3J0PScnLHNzbG1v
ZGU9Jycsb25seXJlYWQ9JycsY29ubl9zZXR0aW5ncz0nJyxkaXNhbGxvd19w
cmVtYXR1cmU9LTEpClszNzAwXWdsb2JhbHMuZXh0cmFfc3lzdGFibGVfcHJl
Zml4ZXMgPSAnZGRfOycKWzM3MDBdZ2xvYmFscy5leHRyYV9zeXN0YWJsZV9w
cmVmaXhlcyA9ICdkZF87Jwo=

------_=_NextPart_001_01C62E32.E00F752E
Content-Type: text/plain
Content-Disposition: inline
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

------_=_NextPart_001_01C62E32.E00F752E--

Re: LATIN1/9 conversion....

> > This is the answer :-)
> > Hmmm. The driver doesn't care this one setting. It override it
> > automatically :-( Are you able to compile the driver yourself?
> > If so I can post you the hint how to disable automatic encoding
> > detection.
>
> I'm sure the driver is doing the setting for the right reason, its

I'm not sure ;-) I even think it makes this the bad way.

> > > > It means you may use "PostgreSQL Unicode" driver instead of
> > > > "PostgreSQL ANSI"
> > >
> > > We have found that the euro symbol and other accented
> > characters are not
> > > correctly stored if we do that. This database is currently
> > coming across
>
> No, we tried a unicode database with the unicode ODBC psqldriver.
> MSAccess couldn't write the correct characters to the database.

Could you try LATIN1 database with Unicode psqlODBC driver?
Does it still break the euro symbol?

> I have had this problem with evry driver from 08.01.01xx to the current
> 08.01.02

Ok. I'll try send you changed psqlODBC 08.01.0200 without autodetecting
client_encoding.

> Regards and thanks for your continuing attention.

Not at all. I was in doubt if autodetecting the encoding after user
connection settings is the right way some time ago.

Regards,

Luf

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Re: LATIN1/9 conversion....

Luf.

> -----Original Message-----
> From: Ludek Finstrle [mailto:luf@pzkagis.cz]=20
> Sent: 10 February 2006 11:32
> To: Tim Clarke
> Cc: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] LATIN1/9 conversion....
>=20
> I'm not sure ;-) I even think it makes this the bad way.
>=20
> Could you try LATIN1 database with Unicode psqlODBC driver?
> Does it still break the euro symbol?

Yes, the only working combination of oracle transfer, java/Linux and
MSAccess/doze clients we can get working is the one we have now.

> Ok. I'll try send you changed psqlODBC 08.01.0200 without=20
> autodetecting
> client_encoding.

Great :)

> Not at all. I was in doubt if autodetecting the encoding after user
> connection settings is the right way some time ago.

Very prescient of you!

> Regards,
>=20
> Luf

Regards

Tim Clarke

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Re: LATIN1/9 conversion....

Ludek Finstrle writes:

> Could you try LATIN1 database with Unicode psqlODBC driver?
> Does it still break the euro symbol?
>

By the way latin9 is the "fixed" version of the obsolete latin1. Among
the fixes there was the addition of the euro symbol.



My two cents.


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Re: LATIN1/9 conversion....

Marc.
That is a useful interjection, ISTR trying many of the combinations of
export coding in latinx from Oracle and postgreSQL database latiny
coding. Not sure if I hit 9 tho. The instant we the overnight oracle
data transfer out of the way I shall try to dump and rebuild the
database in unicode. I hope that cures these issues once and for all...

Tim Clarke

> -----Original Message-----
> From: pgsql-odbc-owner@postgresql.org=20
> [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Marc Herbert
> Sent: 10 February 2006 13:56
> To: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] LATIN1/9 conversion....
>=20
>=20
> Ludek Finstrle writes:
>=20
> > Could you try LATIN1 database with Unicode psqlODBC driver?
> > Does it still break the euro symbol?
> >
>=20
> By the way latin9 is the "fixed" version of the obsolete latin1. Among
> the fixes there was the addition of the euro symbol.
>=20
>
>=20
> My two cents.

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Re: LATIN1/9 conversion....

So what is the upshot of all of this. I have a client who is seeing
the same error messages.

They have tried the unicode driver but get connection errors which
eventually cause IIS to crash.

Dave
On 10-Feb-06, at 9:23 AM, Tim Clarke wrote:

> Marc.
> That is a useful interjection, ISTR trying many of the combinations of
> export coding in latinx from Oracle and postgreSQL database latiny
> coding. Not sure if I hit 9 tho. The instant we the overnight oracle
> data transfer out of the way I shall try to dump and rebuild the
> database in unicode. I hope that cures these issues once and for
> all...
>
> Tim Clarke
>
>> -----Original Message-----
>> From: pgsql-odbc-owner@postgresql.org
>> [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Marc Herbert
>> Sent: 10 February 2006 13:56
>> To: pgsql-odbc@postgresql.org
>> Subject: Re: [ODBC] LATIN1/9 conversion....
>>
>>
>> Ludek Finstrle writes:
>>
>>> Could you try LATIN1 database with Unicode psqlODBC driver?
>>> Does it still break the euro symbol?
>>>
>>
>> By the way latin9 is the "fixed" version of the obsolete latin1.
>> Among
>> the fixes there was the addition of the euro symbol.
>>
>>
>>
>> My two cents.
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 6: explain analyze is your friend
>


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

Re: LATIN1/9 conversion....

Haven't got an "upshot" yet since we don't appear to have a problem
except for the error messages. Sorry, Dave. It only seems to occur here
when we connect a M$ Access front-end database to Postgres and it just
bleats as it connects. I don't have an issue storing any characters that
I need to. We're throwing out all our M$ apps here anyway due to the
huge savings generated; moving all to web front ends.

Tim Clarke

> -----Original Message-----
> From: Dave Cramer [mailto:pg@fastcrypt.com]=20
> Sent: 11 October 2006 20:28
> To: Tim Clarke
> Cc: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] LATIN1/9 conversion....
>=20
>=20
> So what is the upshot of all of this. I have a client who is seeing
> the same error messages.
>=20
> They have tried the unicode driver but get connection errors which
> eventually cause IIS to crash.
>=20
> Dave
> On 10-Feb-06, at 9:23 AM, Tim Clarke wrote:
>=20
> > Marc.
> > That is a useful interjection, ISTR trying many of the=20
> combinations of
> > export coding in latinx from Oracle and postgreSQL database latiny
> > coding. Not sure if I hit 9 tho. The instant we the overnight oracle
> > data transfer out of the way I shall try to dump and rebuild the
> > database in unicode. I hope that cures these issues once and for
> > all...
> >
> > Tim Clarke
> >
> >> -----Original Message-----
> >> From: pgsql-odbc-owner@postgresql.org
> >> [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Marc Herbert
> >> Sent: 10 February 2006 13:56
> >> To: pgsql-odbc@postgresql.org
> >> Subject: Re: [ODBC] LATIN1/9 conversion....
> >>
> >>
> >> Ludek Finstrle writes:
> >>
> >>> Could you try LATIN1 database with Unicode psqlODBC driver?
> >>> Does it still break the euro symbol?
> >>>
> >>
> >> By the way latin9 is the "fixed" version of the obsolete latin1.
> >> Among
> >> the fixes there was the addition of the euro symbol.
> >>
> >>
> >>
> >> My two cents.
> >
> > ---------------------------(end of
> > broadcast)---------------------------
> > TIP 6: explain analyze is your friend
> >
>=20
>=20

---------------------------(end of broadcast)---------------------------
TIP 1: 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

Re: LATIN1/9 conversion....

Hello,

I'm pretty interested about your web front end. I'm thinking about it
and I'm currently looking around about some projects, framework or
classes to speed the dev.

Do you have some advices about it ?
--
+-----------------+
| IoGuiX |
| igxnews@free.fr |
+-----------------+



Tim Clarke wrote:
> Haven't got an "upshot" yet since we don't appear to have a problem
> except for the error messages. Sorry, Dave. It only seems to occur here
> when we connect a M$ Access front-end database to Postgres and it just
> bleats as it connects. I don't have an issue storing any characters that
> I need to. We're throwing out all our M$ apps here anyway due to the
> huge savings generated; moving all to web front ends.
>
> Tim Clarke
>
>> -----Original Message-----
>> From: Dave Cramer [mailto:pg@fastcrypt.com]
>> Sent: 11 October 2006 20:28
>> To: Tim Clarke
>> Cc: pgsql-odbc@postgresql.org
>> Subject: Re: [ODBC] LATIN1/9 conversion....
>>
>>
>> So what is the upshot of all of this. I have a client who is seeing
>> the same error messages.
>>
>> They have tried the unicode driver but get connection errors which
>> eventually cause IIS to crash.
>>
>> Dave
>> On 10-Feb-06, at 9:23 AM, Tim Clarke wrote:
>>
>>> Marc.
>>> That is a useful interjection, ISTR trying many of the
>> combinations of
>>> export coding in latinx from Oracle and postgreSQL database latiny
>>> coding. Not sure if I hit 9 tho. The instant we the overnight oracle
>>> data transfer out of the way I shall try to dump and rebuild the
>>> database in unicode. I hope that cures these issues once and for
>>> all...
>>>
>>> Tim Clarke
>>>
>>>> -----Original Message-----
>>>> From: pgsql-odbc-owner@postgresql.org
>>>> [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Marc Herbert
>>>> Sent: 10 February 2006 13:56
>>>> To: pgsql-odbc@postgresql.org
>>>> Subject: Re: [ODBC] LATIN1/9 conversion....
>>>>
>>>>
>>>> Ludek Finstrle writes:
>>>>
>>>>> Could you try LATIN1 database with Unicode psqlODBC driver?
>>>>> Does it still break the euro symbol?
>>>>>
>>>> By the way latin9 is the "fixed" version of the obsolete latin1.
>>>> Among
>>>> the fixes there was the addition of the euro symbol.
>>>>
>>>>
>>>>
>>>> My two cents.
>>> ---------------------------(end of
>>> broadcast)---------------------------
>>> TIP 6: explain analyze is your friend
>>>
>>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: 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

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Re: LATIN1/9 conversion....

We've been using Coldfusion for our public web-site but that is
expensive. For purely internal maintenance forms I'm seriously
considering Ruby on Rails right now. But this is off the list topic so
email me privately if you want more information.

Tim Clarke

> -----Original Message-----
> From: ioguix [mailto:igxnews@free.fr]=20
> Sent: 12 October 2006 09:00
> To: Tim Clarke
> Cc: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] LATIN1/9 conversion....
>=20
>=20
> Hello,
>=20
> I'm pretty interested about your web front end. I'm thinking about it
> and I'm currently looking around about some projects, framework or
> classes to speed the dev.
>=20
> Do you have some advices about it ?
> --=20
> +-----------------+
> | IoGuiX |
> | igxnews@free.fr |
> +-----------------+
>=20
>=20
>=20
> Tim Clarke wrote:
> > Haven't got an "upshot" yet since we don't appear to have a problem
> > except for the error messages. Sorry, Dave. It only seems=20
> to occur here
> > when we connect a M$ Access front-end database to Postgres=20
> and it just
> > bleats as it connects. I don't have an issue storing any=20
> characters that
> > I need to. We're throwing out all our M$ apps here anyway due to the
> > huge savings generated; moving all to web front ends.
> >=20
> > Tim Clarke
> >=20
> >> -----Original Message-----
> >> From: Dave Cramer [mailto:pg@fastcrypt.com]=20
> >> Sent: 11 October 2006 20:28
> >> To: Tim Clarke
> >> Cc: pgsql-odbc@postgresql.org
> >> Subject: Re: [ODBC] LATIN1/9 conversion....
> >>
> >>
> >> So what is the upshot of all of this. I have a client who=20
> is seeing
> >> the same error messages.
> >>
> >> They have tried the unicode driver but get connection=20
> errors which
> >> eventually cause IIS to crash.
> >>
> >> Dave
> >> On 10-Feb-06, at 9:23 AM, Tim Clarke wrote:
> >>
> >>> Marc.
> >>> That is a useful interjection, ISTR trying many of the=20
> >> combinations of
> >>> export coding in latinx from Oracle and postgreSQL database latiny
> >>> coding. Not sure if I hit 9 tho. The instant we the=20
> overnight oracle
> >>> data transfer out of the way I shall try to dump and rebuild the
> >>> database in unicode. I hope that cures these issues once and for=20=
=20
> >>> all...
> >>>
> >>> Tim Clarke
> >>>
> >>>> -----Original Message-----
> >>>> From: pgsql-odbc-owner@postgresql.org
> >>>> [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of=20
> Marc Herbert
> >>>> Sent: 10 February 2006 13:56
> >>>> To: pgsql-odbc@postgresql.org
> >>>> Subject: Re: [ODBC] LATIN1/9 conversion....
> >>>>
> >>>>
> >>>> Ludek Finstrle writes:
> >>>>
> >>>>> Could you try LATIN1 database with Unicode psqlODBC driver?
> >>>>> Does it still break the euro symbol?
> >>>>>
> >>>> By the way latin9 is the "fixed" version of the obsolete=20
> latin1.
> >>>> Among
> >>>> the fixes there was the addition of the euro symbol.
> >>>>
> >>>>
> >>>>
> >>>> My two cents.
> >>> ---------------------------(end of
> >>> broadcast)---------------------------
> >>> TIP 6: explain analyze is your friend
> >>>
> >>
> >=20
> > ---------------------------(end of=20
> broadcast)---------------------------
> > TIP 1: if posting/reading through Usenet, please send an appropriate
> > subscribe-nomail command to majordomo@postgresql.org=20
> so that your
> > message can get through to the mailing list cleanly
>=20

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings