This is the FAQ for the pgAdmin III tool V1.0.
+
-Encoding Problem: My data is not shown
-Font problem: SQL shows weird characters
+Can't edit table data
+A property is disabled on an object I want to edit
User privileges
-Server log: unsupported protocol
Foreign key constraints not shown
Win9x problems
Query tool hangs on Win9x
Query tool columns truncated
+Server log: unsupported protocol
+Font problem: too big
+Font problem: SQL shows weird characters
Connection to database dropped
+Encoding Problem: My data is not shown
Data that includes non-ascii characters (character code > 0x7f) will not be shown. -
-pgAdmin III 1.0.0 uses the client_encoding set to UNICODE. The server will automatically convert
-all data from the encoding format stored in the database to UNICODE. If the server is not able
-to convert the data, it will suppress this. A common problem is using the SQL_ASCII server side
-encoding, but storing non-ascii data in it. If you're using a client_encoding set to SQL_ASCII,
-you won't notice a problem because the server doesn't convert the data, but when using a different
-client encoding the server starts to convert, and fails.
-Later versions of pgAdmin III (1.0.1 and up) will use SQL_ASCII client encoding, if it detects a server encoding
-of SQL_ASCII. If a different encoding is present, UNICODE is used.
-
[AP]
-
On my *ix system, the text is too big, and is truncated in the controls. +
+When I open a table to edit, there's no empty line at the end to enter new data. I can't edit the existing data either.
-pgAdmin III uses the system's setting for the font, which sometimes
-isn't a good choice.
-Try to put something like this in your ~/.gtkrc-2.0 file:
-
-<---------cut here------------------->
-style "defaultfont"
-{
- font_name = "Arial 8"
-}
-widget_class "*" style "defaultfont"
-<---------cut here------------------->
-
-The forthcoming V1.1 will solve this by resizing the dialogs according to the font in use.
-
[RE]
+In order to edit data, pgAdmin III requires a primary key on the table, which is a good database design practice anyway.
+Alternatively, the table can be created WITH OIDS. Please note that oids are *not* guaranteed to be unique over a very
+long period of time, so using oids as kind-of primary key is only second choice.
+[AP]
-On my system, the reengineered SQL windows shows weird characters, -while it should show non-Latin characters. +I want to edit an object, but the property I'd like to edit always appears disabled.
-By default, pgAdmin III uses a fixed pitch font, to show nicely
-formatted reengineered SQL commands. This may lead to weird characters
-if these are not supported by the fixed font codeset.
-On the Query tab of the Options dialog, you may select your preferred
-font to have a correct display.
-
[AP]
+You're probably editing an object on an older version of PostgreSQL server.
+
+pgAdmin III supports PostgreSQL server versions starting from V7.3. Naturally, constant improvements +add more features. pgAdmin III tries to keep up with this development. +Consequently, some features that are described in the online documentation, which always covers the latest released +PostgreSQL version available, are not accessible on older server versions. In this case, pgAdmin III detects this and +disables the option. +
+Hint: If you're working on older PostgreSQL servers regularly, you can change the online help site in the options dialogue. +[AP]
@@ -70,22 +53,8 @@
It is recommended to organize users into groups, and grant
the rights to these instead of granting rights to individual users.
If you need this nevertheless, you can switch on the option "Show users
-for privileges" on the General tab of the Options dialog.
-
[AP]
-
-Every time I connect to my PostgreSQL 7.3.x server with pgAdmin III,
-I get the following message in the serverlog:
- FATAL: unsupported frontend protocol
-
-Binary distributions of pgAdmin III are linked against the newest
-PostgreSQL libpq 7.4 library, which implements a new frontend protocol. It
-will try to connect to the backend using this protocol first, and if that fails it
-uses the older one.
-This behaviour is by design, and there's no problem to be expected
-from this.
-
[AP]
+for privileges" on the General tab of the Options dialogue.
+[AP]
@@ -101,14 +70,13 @@
by showing a ADD CONSTRAINT when reverse engineering, while actually the constraint information in
the database is missing.
Run the adddepend script, which can be found in the backend's sources contrib/adddepend directory.
-
[AP]
+[AP]
-We're providing a stripped down pgAdmin3 version without unicode support and limited functionality.
+We're providing a stripped down pgAdmin III 1.0 version without unicode support and limited functionality.
Still, Win9x imposes some other problems too. Consider using a true 32bit operating system
-(Linux, W2K, XP) if these constraints hit you.
+(Linux, W2K, XP) if these constraints hit you. We won't provide Win9x compatible pgAdmin III 1.2 versions.
One example:
@@ -126,9 +94,55 @@
You can increase the query option "max. chars per column" for this. Please note that there's another limit for this imposed by the underlying
windows control, which apparently doesn't allow more than 511 characters.
-In V1.1, we provide the function "execute to file", which has no column restrictions. [AP]
-
+Every time I connect to my PostgreSQL 7.3.x server with pgAdmin III,
+I get the following message in the serverlog:
+ FATAL: unsupported frontend protocol
+
+Binary distributions of pgAdmin III are linked against the newest
+PostgreSQL libpq 7.4/8.0 library, which implements a new frontend protocol. It
+will try to connect to the backend using this protocol first, and if that fails it
+uses the older one.
+This behaviour is by design, and there's no problem to be expected
+from this.
+[AP]
+
On my *ix system, the text is too big, and is truncated in the controls. +
+pgAdmin III uses the system's setting for the font, which sometimes
+isn't a good choice.
+Try to put something like this in your ~/.gtkrc-2.0 file:
+
+<---------cut here------------------->
+style "defaultfont"
+{
+ font_name = "Arial 8"
+}
+widget_class "*" style "defaultfont"
+<---------cut here------------------->
+
+pgAdmin III V1.1 and up solves this by resizing the dialogues according to the font in use.
+In addition, you may select you preferred application font in the options dialogue.
+[RE]
+
+On my system, the reengineered SQL windows shows weird characters, +while it should show non-Latin characters. +
+By default, pgAdmin III uses a fixed pitch font, to show nicely
+formatted reengineered SQL commands. This may lead to weird characters
+if these are not supported by the fixed font codeset.
+On the Query tab of the Options dialogue, you may select your preferred
+font to have a correct display.
+[AP]
+
I'm connecting to the database server via a firewall. After some minutes of inactivity, the @@ -160,8 +174,22 @@ If there's absolutely no way to accomplish this, you could use a SSH tunnel for PostgreSQL traffic. SSH can be configured to keep the channel open at all times, so that database traffic can be passed even after a prolonged period of inactivity. For information how to configure this, ask your -SSH package's documentation for "tunneling". [AP] -
+SSH package's documentation for "tunneling". +[AP] +Data that includes non-ascii characters (character code > 0x7f) will not be shown. +
+pgAdmin III 1.0.0 uses the client_encoding set to UNICODE. The server will automatically convert
+all data from the encoding format stored in the database to UNICODE. If the server is not able
+to convert the data, it will suppress this. A common problem is using the SQL_ASCII server side
+encoding, but storing non-ascii data in it. If you're using a client_encoding set to SQL_ASCII,
+you won't notice a problem because the server doesn't convert the data, but when using a different
+client encoding the server starts to convert, and fails.
+Later versions of pgAdmin III (1.0.1 and up) will use SQL_ASCII client encoding, if it detects a server encoding
+of SQL_ASCII. If a different encoding is present, UNICODE is used.
+[AP]
+