Thread: German umlauts in pgadmin III
Hello, I am confronted with a little problem in pgadmin III: Table cells and comments on database objects are not properly displayed if they contain a german umlaut. The table cells just contain ", the comments (on tables, for example) are completly empty. In pgadmin II everything is okay, if I connect via ODBC/Access to the tables, the umlauts are properly displayed, too. Plattform for pgadmin: Win 2000 Database: Postgres 7.3.2 on Debian Linux Woody (3.0), Database encoding SQL_ASCII Thanks in advance, Albin -- ************************************************************************ ** Albin Blaschka, Mag. rer. nat. ** BAL Gumpenstein ** Projekt: Landschaft und Landwirtschaft im Wandel ** Tel.: 03682 / 22451 - 244 ** No trees were killed in the creation of this message. ** However, many electrons were terrible inconvenienced. ************************************************************************
Le Lundi 20 Octobre 2003 10:43, Albin Blaschka a écrit : > Plattform for pgadmin: Win 2000 > Database: Postgres 7.3.2 on Debian Linux Woody (3.0), > Database encoding SQL_ASCII Dear Albin, This problem was fixed in CVS. Two solutions: 1) Wait for a Win32 binary snapshots. There should be one sooner or later from http://www.pgadmin.org/pgadmin3/download.php#snapshots. 2) Use a Latin1 (iso8859-1) or Unicode database to store German text. This should solve your problem without the need to wait for a snapshots. A latin1 database is the recommanded way. Cheers, Jean-Michel
Hi Albin, Albin Blaschka wrote: > Hello, > > I am confronted with a little problem in pgadmin III: > > Table cells and comments on database objects are not > properly displayed if they contain a german umlaut. > The table cells just contain ", the comments (on tables, > for example) are completly empty. > In pgadmin II everything is okay, if I connect via > ODBC/Access to the tables, the umlauts are properly > displayed, too. > > Plattform for pgadmin: Win 2000 > Database: Postgres 7.3.2 on Debian Linux Woody (3.0), > Database encoding SQL_ASCII ^^^^^^^^^^ This is wrong. You cant have Umlauts with ASCII. If you input them, you violate the ASCII codeset, wich is 7 Bit only. You'll have to recode your data to ISO8859-1 (Latin-1) or any superset (UNICODE) Then pgadminIII works as well as any other application. For migration or your apps they should just set their client_encoding to iso8859-1 then (if you choose UNICODE) Regards Tino Wildenhain
Albin Blaschka wrote: >Hello, > >I am confronted with a little problem in pgadmin III: > >Table cells and comments on database objects are not >properly displayed if they contain a german umlaut. >The table cells just contain ", the comments (on tables, >for example) are completly empty. >In pgadmin II everything is okay, if I connect via >ODBC/Access to the tables, the umlauts are properly >displayed, too. > > Umlaute are no ascii chars, so they can't converted to unicode. V1.0.1 which was released some days ago has a workaround for miscoded databases, leaving encoding conversions to the client if the db is created SQL_ASCII. Regards, Andreas
Actually, it's a wording issue: ASCII: 7-bit Extended ASCII (Latin 1): 8-bit Personally, whenever i say ASCII, i usually mean Extended ASCII. Regards. Tino Wildenhain wrote: > Hi Albin, > > Albin Blaschka wrote: > >> Hello, >> >> I am confronted with a little problem in pgadmin III: >> >> Table cells and comments on database objects are not properly >> displayed if they contain a german umlaut. >> The table cells just contain ", the comments (on tables, >> for example) are completly empty. >> In pgadmin II everything is okay, if I connect via >> ODBC/Access to the tables, the umlauts are properly >> displayed, too. >> >> Plattform for pgadmin: Win 2000 >> Database: Postgres 7.3.2 on Debian Linux Woody (3.0), >> Database encoding SQL_ASCII > > ^^^^^^^^^^ > > This is wrong. You cant have Umlauts with ASCII. > If you input them, you violate the ASCII codeset, > wich is 7 Bit only. > You'll have to recode your data to ISO8859-1 > (Latin-1) or any superset (UNICODE) > Then pgadminIII works as well as any other > application. For migration or your apps > they should just set their client_encoding > to iso8859-1 then (if you choose UNICODE) > > Regards > Tino Wildenhain > > > ---------------------------(end of broadcast)--------------------------- > TIP 8: explain analyze is your friend > -- Sincerely, Reshat. ------------------------------------------------------------------------------------------- If you see my certificate with this message, you should be able to send me encrypted e-mail. Please consult your e-mail client for details if you would like to do that.
Hi Reshat Sabiq, Reshat Sabiq wrote: > Actually, it's a wording issue: > ASCII: 7-bit > Extended ASCII (Latin 1): 8-bit > > Personally, whenever i say ASCII, i usually mean Extended ASCII. No matter what you say, but postgres knows your "extended ascii" by the name Latin1 :-) (or iso8859-1) While SQL ASCII is a complete other encoding. Regards Tino Wildenhain
> -----Original Message----- > From: Andreas Pflug [mailto:pgadmin@pse-consulting.de] > Sent: 20 October 2003 10:07 > To: Albin Blaschka > Cc: 'pgadmin-support@postgresql.org'; Reinhard Resch; Wilhelm Graiss > Subject: Re: [pgadmin-support] German umlauts in pgadmin III > > Umlaute are no ascii chars, so they can't converted to unicode. > V1.0.1 which was released some days ago has a workaround for > miscoded databases, leaving encoding conversions to the > client if the db is created SQL_ASCII. I just ran into this on my system with the £ symbol (UK Pound symbol, not #), however the fix doesn't seem to work in CVStip - Any column that contains a £ value anywhere in it shows up as having a null value. At very least I would expectto see an 'unknown char' symbol in place of the pound sign, and the rest of the string intact. Regards, Dave.
> Hello, > > Thanks for all the answers, I solved the problem with "converting" my > databases to Latin1... > (dumping the data, dropping the DB, recreate it with Latin1, reloading > data) > > Was quite an effort, but did it and without problems... > > BTW: PGAdmin III, V1.01 did *not* work in that case (displaying german > umlaute properly...) > > Thanks, > Albin > > -- > ************************************************************************ > ** Albin Blaschka, Mag. rer. nat. > ** BAL Gumpenstein > ** Projekt: Landschaft und Landwirtschaft im Wandel > ** Tel.: 03682 / 22451 - 244 > ** No trees were killed in the creation of this message. > ** However, many electrons were terrible inconvenienced. > ************************************************************************ > > > > > > ---------- > Von: Dave Page[SMTP:dpage@vale-housing.co.uk] > Gesendet: Mittwoch, 22. Oktober 2003 13:28 > An: Andreas Pflug; Albin Blaschka > Cc: pgadmin-support@postgresql.org; Reinhard Resch; Wilhelm Graiss > Betreff: RE: [pgadmin-support] German umlauts in pgadmin III > > > > > -----Original Message----- > > From: Andreas Pflug [mailto:pgadmin@pse-consulting.de] > > Sent: 20 October 2003 10:07 > > To: Albin Blaschka > > Cc: 'pgadmin-support@postgresql.org'; Reinhard Resch; Wilhelm Graiss > > Subject: Re: [pgadmin-support] German umlauts in pgadmin III > > > > Umlaute are no ascii chars, so they can't converted to unicode. > > V1.0.1 which was released some days ago has a workaround for > > miscoded databases, leaving encoding conversions to the > > client if the db is created SQL_ASCII. > > I just ran into this on my system with the £ symbol (UK Pound symbol, not > #), however the fix doesn't seem to work in CVS tip - Any column that > contains a £ value anywhere in it shows up as having a null value. At very > least I would expect to see an 'unknown char' symbol in place of the pound > sign, and the rest of the string intact. > > Regards, Dave. > >
Albin Blaschka wrote: >>Hello, >> >>Thanks for all the answers, I solved the problem with "converting" my >>databases to Latin1... >>(dumping the data, dropping the DB, recreate it with Latin1, reloading >>data) >> >>Was quite an effort, but did it and without problems... >> >>BTW: PGAdmin III, V1.01 did *not* work in that case (displaying german >>umlaute properly...) >> >>Thanks, >>Albin >> >>-- >>************************************************************************ >>** Albin Blaschka, Mag. rer. nat. >>** BAL Gumpenstein >>** Projekt: Landschaft und Landwirtschaft im Wandel >>** Tel.: 03682 / 22451 - 244 >>** No trees were killed in the creation of this message. >>** However, many electrons were terrible inconvenienced. >>************************************************************************ >> >> >> >> >> >>---------- >>Von: Dave Page[SMTP:dpage@vale-housing.co.uk] >>Gesendet: Mittwoch, 22. Oktober 2003 13:28 >>An: Andreas Pflug; Albin Blaschka >>Cc: pgadmin-support@postgresql.org; Reinhard Resch; Wilhelm Graiss >>Betreff: RE: [pgadmin-support] German umlauts in pgadmin III >> >> >> >> >> >>>-----Original Message----- >>>From: Andreas Pflug [mailto:pgadmin@pse-consulting.de] >>>Sent: 20 October 2003 10:07 >>>To: Albin Blaschka >>>Cc: 'pgadmin-support@postgresql.org'; Reinhard Resch; Wilhelm Graiss >>>Subject: Re: [pgadmin-support] German umlauts in pgadmin III >>> >>>Umlaute are no ascii chars, so they can't converted to unicode. >>>V1.0.1 which was released some days ago has a workaround for >>>miscoded databases, leaving encoding conversions to the >>>client if the db is created SQL_ASCII. >>> >>> >>I just ran into this on my system with the £ symbol (UK Pound symbol, not >>#), however the fix doesn't seem to work in CVS tip - Any column that >>contains a £ value anywhere in it shows up as having a null value. At very >>least I would expect to see an 'unknown char' symbol in place of the pound >>sign, and the rest of the string intact. >> >>Regards, Dave. >> >> >> >> While the conversion *is* correctly determined for each connection, it wasn't applied in pgSet... Done now (head and trunk). Regards, Andreas