Downgrade of MySQL

[Shelly]

I am running into a character problem and I am seeking a little advice.

The client is moving his code from one server to another. The destination
server has MySQL 4.0.7 and the host will not upgrade. The source server has
MySql 4.1.22.

On the source server a string with an apostrophe that was written to the
database displays properly. Porting those data to the destination site, and
using the same code, produces strange results. For example, the apostrophe
(value=39) displays as the characters for the sequence with values of 226,
128, 153.

If I put in a new string with an apostrophe via php code on the destination
server, then retrieval of that string displays properly there.

For the old strings I have tried stripslashes, but this had no effect.

This is not the only situation. The word cafe, for example, with the
(whatever-kind-it-is) accent also displays poorly ont the destination
server.

In summary: On the destination system all new data will display properly.
However, old data do not.

Suggestions?

--
Shelly

[The Natural Philosopher]

Shelly wrote:

I am running into a character problem and I am seeking a little advice.

The client is moving his code from one server to another. The destination
server has MySQL 4.0.7 and the host will not upgrade. The source server has
MySql 4.1.22.

On the source server a string with an apostrophe that was written to the
database displays properly. Porting those data to the destination site, and
using the same code, produces strange results. For example, the apostrophe
(value=39) displays as the characters for the sequence with values of 226,
128, 153.

If I put in a new string with an apostrophe via php code on the destination
server, then retrieval of that string displays properly there.

For the old strings I have tried stripslashes, but this had no effect.

This is not the only situation. The word cafe, for example, with the
(whatever-kind-it-is) accent also displays poorly ont the destination
server.

In summary: On the destination system all new data will display properly.
However, old data do not.

Suggestions?

I suspect its not the age of the Mysql, but a php/mysql config issue.

Is it magicl sashes?

Stucklehead will probably come along and tell you all you never wanted
to know..

[NC]

On Nov 13, 9:45 am, "Shelly" <[e-mail]:

>
The client is moving his code from one server to another.
The destination server has MySQL 4.0.7 and the host will
not upgrade. The source server has MySql 4.1.22.

And what are the default character sets on the two servers?

On the source server a string with an apostrophe that was
written to the database displays properly. Porting those
data to the destination site, and using the same code,
produces strange results. For example, the apostrophe
(value=39) displays as the characters for the sequence
with values of 226, 128, 153.

Which is the Unicode rendition of &rsquo;...

This is not the only situation. The word cafe, for
example, with the (whatever-kind-it-is) accent also
displays poorly ont the destination server.

Another reason to suspect a character set problem...

In summary: On the destination system all new data will
display properly. However, old data do not.

Suggestions?

Three: (1) character set, (2) character set, and (3) character set. I
would guess that the source server is configured with Latin-1 (or
similar) default encoding, while the destination server is configured
with UTF-8...

Cheers,
NC

[Shelly]

The Natural Philosopher wrote:

Shelly wrote:

>I am running into a character problem and I am seeking a little
advice. The client is moving his code from one server to another. The
destination server has MySQL 4.0.7 and the host will not upgrade. The
source server has MySql 4.1.22.

On the source server a string with an apostrophe that was written to
the database displays properly. Porting those data to the
destination site, and using the same code, produces strange results.
For example, the apostrophe (value=39) displays as the characters
for the sequence with values of 226, 128, 153.

If I put in a new string with an apostrophe via php code on the
destination server, then retrieval of that string displays properly
there. For the old strings I have tried stripslashes, but this had no
effect. This is not the only situation. The word cafe, for example, with
the
(whatever-kind-it-is) accent also displays poorly ont the destination
server.

In summary: On the destination system all new data will display
properly. However, old data do not.

Suggestions?

I suspect its not the age of the Mysql, but a php/mysql config issue.

Is it magicl sashes?

When I look at the data via phpMyAdmin, I see an apostrophe. When I expand
the result I fetch via php code, it shows that sequence.

>
Stucklehead will probably come along and tell you all you never wanted
to know..

I doubt it. He thinks I am lazy and "stoooopid". Oh, and a performation in
a donkey. But, I'll welcome any and all helpful hints.

--
Shelly

[Shelly]

NC wrote:

On Nov 13, 9:45 am, "Shelly" <[e-mail]:

>>
The client is moving his code from one server to another.
The destination server has MySQL 4.0.7 and the host will
not upgrade. The source server has MySql 4.1.22.

And what are the default character sets on the two servers?

On the destination it IS UTF-8. On the source, I guess it is Latin. (It
says en-us)

>

>On the source server a string with an apostrophe that was
written to the database displays properly. Porting those
data to the destination site, and using the same code,
produces strange results. For example, the apostrophe
(value=39) displays as the characters for the sequence
with values of 226, 128, 153.

Which is the Unicode rendition of &rsquo;...

>This is not the only situation. The word cafe, for
example, with the (whatever-kind-it-is) accent also
displays poorly ont the destination server.

Another reason to suspect a character set problem...

>In summary: On the destination system all new data will
display properly. However, old data do not.

Suggestions?

Three: (1) character set, (2) character set, and (3) character set. I
would guess that the source server is configured with Latin-1 (or
similar) default encoding, while the destination server is configured
with UTF-8...

It seems that you are right on. Now I have to figure out the conversions.

--
Shelly

[Shelly]

NC wrote:

On Nov 13, 9:45 am, "Shelly" <[e-mail]:

>Suggestions?

Three: (1) character set, (2) character set, and (3) character set. I
would guess that the source server is configured with Latin-1 (or
similar) default encoding, while the destination server is configured
with UTF-8...

I guess the best thing for me to do is convert the column in the table from
Latin1 to UTF-8.

--
Shelly