Re: [pgadmin-support] connection SSL combobox empty

2003-10-20 Thread Jean-Michel POURE
Le Samedi 18 Octobre 2003 01:37, [EMAIL PROTECTED] a écrit :
> on Mandrake 9.1, pgAdmin III 1.0.1 binary distribution (rpm).
> SSL combobox in connection window is empty :(

If you really need SSL, please install the latest snapshots, i.e.
http://www.pgadmin.org/snapshots/linux/mandrake91/
pgadmin3-1.1.0-cvs20031019.i586.rpm

I was not able to test the build. Do not hesitate to report any problem.

Cheers,
Jean-Michel


---(end of broadcast)---
TIP 6: Have you searched our list archives?

   http://archives.postgresql.org


[pgadmin-support] German umlauts in pgadmin III

2003-10-20 Thread Albin Blaschka

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.







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

   http://www.postgresql.org/docs/faqs/FAQ.html


Re: [pgadmin-support] German umlauts in pgadmin III

2003-10-20 Thread Jean-Michel POURE
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


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


Re: [pgadmin-support] German umlauts in pgadmin III

2003-10-20 Thread Tino Wildenhain
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


Re: [pgadmin-support] German umlauts in pgadmin III

2003-10-20 Thread Andreas Pflug
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


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


Re: [pgadmin-support] German umlauts in pgadmin III

2003-10-20 Thread Reshat Sabiq
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.



smime.p7s
Description: S/MIME Cryptographic Signature


Re: [pgadmin-support] German umlauts in pgadmin III

2003-10-20 Thread Tino Wildenhain
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
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
  http://www.postgresql.org/docs/faqs/FAQ.html