Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Mysql 4.1 experience


boxtel

Recommended Posts

I have tried, 1 time, to upgrade to mysql 4.1 but I had to downgrade again real quick because I could not get my chinese to display right.

 

4.1 has a different scheme for handling encodings and I had not anticipated that. Also, it uses a broader authentication scheme that may/will affect older clients when using passwords.

 

Anybody made a successful effort ?

Treasurer MFC

Link to comment
Share on other sites

I have been running it for a while on my development machine without issue. However, all of my sites are simply in English since I do not cater to the International audience and only do business within the United States. Because of this, I wouldn't have encountered any collation issues.

 

I do know there was an issue with HEAP tables which are good when you have small records of information that are used a lot because they are stored in memory for faster reads and writes. This was supposed to have been fixed in 4.1.8 though.

Link to comment
Share on other sites

  • 6 months later...

Anyone had any experience with this over the past 6 months? I'm getting ready to move a multilingual site to a system with mysql 4.1.

 

Before I dive in I would appreciate any experiences or hints related to making the change.

Link to comment
Share on other sites

be warned PHP 4 will not work with MySQL 4.1. MySQL 4.1 uses a new authentication scheme that PHP 4 does not support. You will either have to use MySQL 4.1 in old password mode, or recompile your PHP to use the mysqli extension, and then change all your mysql_* function calls to mysqli_*

The only thing necessary for evil to flourish is for good men to do nothing

- Edmund Burke

Link to comment
Share on other sites

Thanks for the hint. I think I have the php/mysql 4.1 situation under control. Everything works fine under a one language test.

 

My main concern is related to oscommerce and multiple languages. Since the new charset and collation settings won't allow us to keep mixed language fields anymore I'm curious how others have taken care of this. For example, in the product description table. Even though there is a language id to identify the language of the description with the field charset/collation is there a workaround or are people additing additional fields for each language and setting those fields to the appropriate characterset? What about the address book table? Adding additional fields for each address entry for each language would be a lot of trouble to manage.

 

Is there a decent work around by storing data in a unicode format and then converting based on the language being used? Is there anyway to keep the database table/field structure?

 

I'm testing some things now but spend most of my time scratching my head.

Link to comment
Share on other sites

Yes, sorry I should have mentioned that UFT8 is my last resort. The site I am dealing with includes Japanese and I'm butting against a bit of resistance to the use of unicode rather than the more common character sets for displaying the Japanese side of the site. There are actually some minor discrepencies between the way text is displayed in unicode and the other formats but they are so minor I personally wouldn't be concerned.

 

Anyway, that is more of a human relations problem then a technical one. I will finish testing with unicode and try to sell them on that. I was just curious if anyone was doing anything else.

 

I greatly appreciate your input. "Why not use UTF8?" actually boosts my confidence in that decision. Thanks.

Link to comment
Share on other sites

yeah tell them if they want multi-lingual then UTF8 is not only pretty much the only option, but also the best option, and most widely accepted. ;)

The only thing necessary for evil to flourish is for good men to do nothing

- Edmund Burke

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...