> On Fri, Aug 04, 2006 at 10:48:17AM +0200, [EMAIL PROTECTED] wrote:
>> Hello all,
>>
>> I somehow managed to stuff up the encoding (or locale or something) in a
>> transfer of a database from one machine to another (also different linux
>> distribution).
>>
>> The problem is this: the origional database was created and populated
>> with data using whatever default locale/encoding was installed on the
>> first machine.
>
> Two big questions:
>
> 1. What encoding are the two database (\l will tell you)?
> 2. What encoding are the clients expecting?
Thanks for the response, Martijn.
I *think* the client_encoding origionally in the db was UTF-8 (but I could
be wrong, it might have been LATIN1). I would imagine that LATIN1 would
be the right one, since it needs to display standard english, plus some
others (such as é ä ë è etc).
The multibyte chars show up in xterm (putty) -and- when the data is
displayed using php in a browser - both incorrectly.
I've even tried using LATIN1 (ie, explicitly setting it to latin1 using
initdb, and then restoring the database after changing the 'utf-8' strings
in the dump data to 'latin1'). This still yields the funny chars.
To be honest, I have no idea what the origional encoding was.
Can you suggest any other approaches I can try to restore the database so
that those chars display correctly?
All comments are welcome.
Regards
Henk
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
