Error creating server with pgadmin

Question

I´m using pgadmin and I´ve created a server, when trying to connect I get the following error:

Have you ever seen this problem?

Many thanks

Answer 1

It might be that pgAdmin is trying to connect to the database pruebas expecting it to be encoded as UTF-8. If you think of your database as a file, the client is trying to decode all the byte sequences in it using "the rules of UTF-8" as it were, it comes across the byte sequence 0xF3 which it cannot interpret and therefore fails.

This may be due to the fact that the encoding that you are using on the host computer (the computer where you created the database) is not UTF-8 and when you created the database pruebas you didn't explicitly specify which encoding to use and the creation process used your local setting (whatever it may be) as the default.

The documentation on the supported character sets (specific to version 9.6) says that:

Each database's character set must be compatible with the database's LC_CTYPE (character classification) and LC_COLLATE (string sort order) locale settings. For C or POSIX locale, any character set is allowed, but for other locales there is only one character set that will work correctly. (On Windows, however, UTF-8 encoding can be used with any locale.)

I don't know the details of your OS, but on Linux, I can run the command:

locale

to see all the locale specific information which tells me that my LC_TYPE (which stands for character classification and case conversion) is en_GB.UTF-8 and I can also connect to my DB using the client psql and run:

SHOW server_encoding;

to see the encoding of my database, e.g.:

 server_encoding 
-----------------
 UTF8
(1 row)

If the database pruebas is a small play database you created to play around with and you don't mind deleting it, you could drop it and create it again setting the encoding to UTF-8 and then see if you can connect to it.

I once didn't check the locale on the host (Linux) prior to initialising a database, went ahead and created the database only to find out that the process set up the database using the encoding on the host as default (which wasn't what I wanted). After digging around in the documentation, I found out that the only way to set the locale of the DB to what I wanted was to start all over.