Thread: Error message while connecting to a UNICODE db
Dear friends, while testing things for hiroshi, I found this problem on my installation: (I read the FAQ and BUGS.txt, but as you know I'm not a good reader and I always need to wash my eyes... :p) pgsql server 7.3.4 with db created in "UNICODE". pgadmin3 latest snapshot (today's one) Observed on debian stable and unstable When I connect to the db, I have a popup window telling me that "An Error occured". On the console I can see this warning: ** (pgadmin3:24606): WARNING **: Invalid UTF8 string passed to pango_layout_set_text() And here is pgadmin3 log file: 2003-11-26 19:25:37 INFO : Destroying a connect dialogue 2003-11-26 19:25:37 STATUS : Connecting to database... 2003-11-26 19:25:37 INFO : Creating pgConn object 2003-11-26 19:25:37 INFO : Server name: 192.169.0.254 (resolved to: 192.169.0.254) 2003-11-26 19:25:37 INFO : Opening connection with connection string: hostaddr='192.169.0.254' dbname='template1' user='xxx' password='yyy' port=5432 2003-11-26 19:25:37 QUERY : Set query (192.169.0.254:5432): SELECT pg_encoding_to_char(encoding) AS encoding, datlastsysoid FROM pg_database WHERE datname='template1' 2003-11-26 19:25:37 INFO : Creating pgSet object 2003-11-26 19:25:37 INFO : Setting client_encoding to 'UNICODE' 2003-11-26 19:25:37 ERROR : ?????????????????????????????????????????????????????????????????????????????????????????????????????????T (the final '?' are not mine... they are in the logfile). If it's a known issue, just tell me to go to bed (I promise, I'll do it)! Any idea ? Regards, Raphaël
Raphaël Enrici wrote: > Dear friends, > > while testing things for hiroshi, I found this problem on my > installation: > (I read the FAQ and BUGS.txt, but as you know I'm not a good reader > and I always need to wash my eyes... :p) > pgsql server 7.3.4 with db created in "UNICODE". > pgadmin3 latest snapshot (today's one) > Observed on debian stable and unstable > > When I connect to the db, I have a popup window telling me that "An > Error occured". > On the console I can see this warning: > ** (pgadmin3:24606): WARNING **: Invalid UTF8 string passed to > pango_layout_set_text() > > And here is pgadmin3 log file: > 2003-11-26 19:25:37 INFO : Destroying a connect dialogue > 2003-11-26 19:25:37 STATUS : Connecting to database... > 2003-11-26 19:25:37 INFO : Creating pgConn object > 2003-11-26 19:25:37 INFO : Server name: 192.169.0.254 (resolved to: > 192.169.0.254) > 2003-11-26 19:25:37 INFO : Opening connection with connection > string: hostaddr='192.169.0.254' dbname='template1' user='xxx' > password='yyy' port=5432 > 2003-11-26 19:25:37 QUERY : Set query (192.169.0.254:5432): SELECT > pg_encoding_to_char(encoding) AS encoding, datlastsysoid > FROM pg_database WHERE datname='template1' > 2003-11-26 19:25:37 INFO : Creating pgSet object > 2003-11-26 19:25:37 INFO : Setting client_encoding to 'UNICODE' > 2003-11-26 19:25:37 ERROR : > ?????????????????????????????????????????????????????????????????????????????????????????????????????????T > > > (the final '?' are not mine... they are in the logfile). > > If it's a known issue, just tell me to go to bed (I promise, I'll do it)! Sorry, you must stay awake :-P Does the user name contain non-ASCII chars? Regards, Andreas
Andreas Pflug wrote: > Raphaël Enrici wrote: > >> ... >> And here is pgadmin3 log file: >> 2003-11-26 19:25:37 INFO : Destroying a connect dialogue >> 2003-11-26 19:25:37 STATUS : Connecting to database... >> 2003-11-26 19:25:37 INFO : Creating pgConn object >> 2003-11-26 19:25:37 INFO : Server name: 192.169.0.254 (resolved to: >> 192.169.0.254) >> 2003-11-26 19:25:37 INFO : Opening connection with connection >> string: hostaddr='192.169.0.254' dbname='template1' user='xxx' >> password='yyy' port=5432 >> 2003-11-26 19:25:37 QUERY : Set query (192.169.0.254:5432): SELECT >> pg_encoding_to_char(encoding) AS encoding, datlastsysoid >> FROM pg_database WHERE datname='template1' >> 2003-11-26 19:25:37 INFO : Creating pgSet object >> 2003-11-26 19:25:37 INFO : Setting client_encoding to 'UNICODE' >> 2003-11-26 19:25:37 ERROR : >> ?????????????????????????????????????????????????????????????????????????????????????????????????????????T >> >> >> (the final '?' are not mine... they are in the logfile). >> >> If it's a known issue, just tell me to go to bed (I promise, I'll do >> it)! > > > > Sorry, you must stay awake :-P hehe, what will my wife say! :-p > > > Does the user name contain non-ASCII chars? not at all. The user I use is "ralph"... ooops I said it :) Regards, Raphaël
Raphaël Enrici wrote: >>> >>> And here is pgadmin3 log file: >>> 2003-11-26 19:25:37 INFO : Destroying a connect dialogue >>> 2003-11-26 19:25:37 STATUS : Connecting to database... >>> 2003-11-26 19:25:37 INFO : Creating pgConn object >>> 2003-11-26 19:25:37 INFO : Server name: 192.169.0.254 (resolved >>> to: 192.169.0.254) >>> 2003-11-26 19:25:37 INFO : Opening connection with connection >>> string: hostaddr='192.169.0.254' dbname='template1' user='xxx' >>> password='yyy' port=5432 >>> 2003-11-26 19:25:37 QUERY : Set query (192.169.0.254:5432): SELECT >>> pg_encoding_to_char(encoding) AS encoding, datlastsysoid >>> FROM pg_database WHERE datname='template1' >>> 2003-11-26 19:25:37 INFO : Creating pgSet object >>> 2003-11-26 19:25:37 INFO : Setting client_encoding to 'UNICODE' >>> 2003-11-26 19:25:37 ERROR : >>> ?????????????????????????????????????????????????????????????????????????????????????????????????????????T >>> >> Sorry to come back on this so late. Seems as if a message box is to be displayed, but the error string is corrupted, so pango will hickup. The message originates from the pgConn ctor (line 163), where the conversion from UTF8 to wchar_t is missing. Corrected in cvs, can you verify that your problem's gone? Regards, Andreas
Hi Andreas, Andreas Pflug wrote: > Raphaël Enrici wrote: > >>>> And here is pgadmin3 log file: >>>> 2003-11-26 19:25:37 INFO : Destroying a connect dialogue >>>> 2003-11-26 19:25:37 STATUS : Connecting to database... >>>> 2003-11-26 19:25:37 INFO : Creating pgConn object >>>> 2003-11-26 19:25:37 INFO : Server name: 192.169.0.254 (resolved >>>> to: 192.169.0.254) >>>> 2003-11-26 19:25:37 INFO : Opening connection with connection >>>> string: hostaddr='192.169.0.254' dbname='template1' user='xxx' >>>> password='yyy' port=5432 >>>> 2003-11-26 19:25:37 QUERY : Set query (192.169.0.254:5432): SELECT >>>> pg_encoding_to_char(encoding) AS encoding, datlastsysoid >>>> FROM pg_database WHERE datname='template1' >>>> 2003-11-26 19:25:37 INFO : Creating pgSet object >>>> 2003-11-26 19:25:37 INFO : Setting client_encoding to 'UNICODE' >>>> 2003-11-26 19:25:37 ERROR : >>>> ?????????????????????????????????????????????????????????????????????????????????????????????????????????T >>>> >>> >>> > Sorry to come back on this so late. Are you joking ? You took less than a week! :) I am late in testing, that's the only thing which is true! ;p > Seems as if a message box is to be displayed, but the error string is > corrupted, so pango will hickup. > The message originates from the pgConn ctor (line 163), where the > conversion from UTF8 to wchar_t is missing. > Corrected in cvs, can you verify that your problem's gone? As usual it's ok! I can now read the error message correctly... Now, I'm gonna look for what it means :) You can find a screenshot here: http://perso.club-internet.fr/blacknoz/pgadmin3/Screenshot.jpg Thank you Andreas, Raphaël
Raphaël Enrici wrote: >>>> >> Sorry to come back on this so late. > > > Are you joking ? You took less than a week! :) I am late in testing, > that's the only thing which is true! ;p Well, usually we're fixing in less than 24 hours, with an average reaction time of 6 hours. So this was a bit out of standard deviation :-) > > As usual it's ok! I can now read the error message correctly... Now, > I'm gonna look for what it means :) > You can find a screenshot here: MULE_INTERNAL->UNICODE not possible, I thought *every* server encoding could be read with client_encoding unicode... Just checked, there's no conversion indeed. What the heck is that at all? I didn't find *any* site that's not referencing pgsql when searching for MULE_INTERNAL. Regards, Andreas
Andreas Pflug wrote: > > MULE_INTERNAL->UNICODE not possible, I thought *every* server encoding > could be read with client_encoding unicode... > Just checked, there's no conversion indeed. What the heck is that at > all? I didn't find *any* site that's not referencing pgsql when > searching for MULE_INTERNAL. Fixed: pgAdmin3 won't try to use Unicode if server encoding is MULE_INTERNAL. Raphael, since you're using this encoding, what is it good for? Regards, Andreas
Andreas Pflug wrote: > Andreas Pflug wrote: > >> MULE_INTERNAL->UNICODE not possible, I thought *every* server >> encoding could be read with client_encoding unicode... >> Just checked, there's no conversion indeed. What the heck is that at >> all? I didn't find *any* site that's not referencing pgsql when >> searching for MULE_INTERNAL. > > Fixed: pgAdmin3 won't try to use Unicode if server encoding is > MULE_INTERNAL. > Raphael, since you're using this encoding, what is it good for? In fact I thought I was not. I'm sorry I don't know anything about MULE_INTERNAL... (this is a real admittance of total ignorance from myself... It looks like it has something to do with what is used in emacs [a friend of you as far as I remember]). In fact I configured my db to set UNICODE by default and thought it was the one used. I'll have a look to the config file generated by the postgresql debian package debconf forms and try to overlook where this MULE_INTERNAL reference comes from... Hope you were not too disappointed by lack of knowledge... Regards, Raphaël
Raphaël Enrici wrote: > > In fact I thought I was not. I'm sorry I don't know anything about > MULE_INTERNAL... (this is a real admittance of total ignorance from > myself... It looks like it has something to do with what is used in > emacs [a friend of you as far as I remember]). In fact I configured my > db to set UNICODE by default and thought it was the one used. > I'll have a look to the config file generated by the postgresql debian > package debconf forms and try to overlook where this MULE_INTERNAL > reference comes from... > > Hope you were not too disappointed by lack of knowledge... Deeply! :-) Well, if it's an EMACS mode, I should consider switching to MULE_INTERNAL... Regards, Andreas
Andreas Pflug wrote: > Raphaël Enrici wrote: > >> In fact I thought I was not. I'm sorry I don't know anything about >> MULE_INTERNAL... (this is a real admittance of total ignorance from >> myself... It looks like it has something to do with what is used in >> emacs [a friend of you as far as I remember]). In fact I configured >> my db to set UNICODE by default and thought it was the one used. >> I'll have a look to the config file generated by the postgresql >> debian package debconf forms and try to overlook where this >> MULE_INTERNAL reference comes from... >> Hope you were not too disappointed by lack of knowledge... > > Deeply! :-) Shame on me! :) > Well, if it's an EMACS mode, I should consider switching to > MULE_INTERNAL... That's what I was suggesting :) I can't understand you didn't see it! ;p I just had a quick look to template1 and it is effectively in MULE_INTERNAL. I think this is the rest of some testing I did about 3 or 4 weeks ago... I didn't clear my environment after that. That's why template1 is in EMULE_INTERNAL... Regards, Raphaël aka "MULE_INTERNAL"
Raphaël Enrici wrote: >>> >>> Hope you were not too disappointed by lack of knowledge... >> >> >> Deeply! :-) > > > Shame on me! :) Well, I'm considering forgiving you. This time... > > > Regards, > Raphaël aka "MULE_INTERNAL" At least mule, not donkey :-) Regards, Andreas