Ignore me, I just finally scrolled down to the bottom of the handbook page you linked to :p On 1/20/06, andrew morton <drewish@katherinehouse.com> wrote:

First off, thanks for the head up. I'd just been looking at that update.

I want to make sure I'm clear on this. Update 169 got the core tables but we still need up update our tables. If you're using the .install files, I'm assuming that can be something as simple as: function review_update_2() { return _system_update_utf8(array('review')); }

Does that sound right?

andrew

On 1/20/06, Steven Wittens <steven@acko.net> wrote:

...

Heads up,

I committed my UTF-8 patch (http://drupal.org/node/40515). Looks big, but it really isn't /that/ scary. (*)

But because of this, we need to apply an upgrade to all tables. So, if you have a contrib module with tables, please go to:

http://drupal.org/node/22218#utf8_sql ( http://drupal1.osuosl.org/node/22218#utf8_sql )

Don't worry, it's just a quick copy/paste operation, really. Takes only 5 minutes. Aren't you glad drumm made that awesome update system? ;)

Thanks, Steven Wittens

(*) And it fixes the last of the UTF-8 issues: database field lengths are now guaranteed to be expressed in characters, not bytes. SQL operations like substring, lower, etc are guaranteed to work. Alphabetical ordering can sort accented letters properly. And much more.

Hi, If you are running php5, then there is a fatal bug that I found. Try running the update script with js turned off, and you will see the error. I actually found the Firefox NoScript extension really handy for this. Gordon. On Fri, 2006-01-20 at 22:02 -0500, Syscrusher wrote:

On Friday 20 January 2006 21:01, Steven Wittens wrote:

...

Heads up,

I committed my UTF-8 patch (http://drupal.org/node/40515). Looks big, but it really isn't /that/ scary. (*)

But because of this, we need to apply an upgrade to all tables. So, if you have a contrib module with tables, please go to:

http://drupal.org/node/22218#utf8_sql ( http://drupal1.osuosl.org/node/22218#utf8_sql )

Don't worry, it's just a quick copy/paste operation, really. Takes only 5 minutes. Aren't you glad drumm made that awesome update system? ;)

Thanks, Steven Wittens

Eek! I happened to be building a new sandbox site for myself and checked out CVS just before or just after you committed that update. When I try to run the update.php script against my previous 4.7 HEAD database, it loops endlessly doing.....something. I'm not sure what it's up to, but the behavior is repeatable. Maybe I'm the only one to whom this will happen, because I may have gotten a weird half-updated Drupal snapshot, but I thought I ought to report it. In this case, no big deal -- just a sandbox, and I can nuke it and start over. But I wouldn't want this to happen on a production site.

Yes, I know to back up my database first. In this case, I didn't bother because of it being a sandbox. :-)

It seems as if maybe the hang is in a redirection, because I was seeing repeated HTTP requests in my "netstat" output.

I'm going to rebuild the site. Again, I'm not asking for help solving this, because I think I just got a bogus half-committed version, but I wanted to report it just on the off chance that someone else also sees it and it starts to smell like a pattern.

Scott

I am also getting these errors now: Warning: Illegal mix of collations (utf8_general_ci,COERCIBLE) and (latin1_swedish_ci,IMPLICIT) for operation 'like' query: SELECT * FROM access WHERE status = 1 AND type = 'host' AND LOWER('192.168.0.2') LIKE LOWER(mask) in .../includes/database.mysql.inc on line 118

Khalid B wrote:

In order to solve this, you either have to run the update for the specific module, or you can do it manually for every table like so:

ALTER TABLE vocabulary_node_types CONVERT TO CHARACTER SET utf8;

That takes care of the illegal mix of collations errors.

On 1/21/06, Khalid B <kb@2bits.com> wrote:

...

I am also getting these errors now:

Warning: Illegal mix of collations (utf8_general_ci,COERCIBLE) and (latin1_swedish_ci,IMPLICIT) for operation 'like' query: SELECT * FROM access WHERE status = 1 AND type = 'host' AND LOWER('192.168.0.2') LIKE LOWER(mask) in .../includes/database.mysql.inc on line 118

You just have to scroll down the page and continue with the update. This is a warning, thats all. No need to do anything manually. I already posted about this in this thread.

In order to solve this, you either have to run the update for the specific module, or you can do it manually for every table like so:

ALTER TABLE vocabulary_node_types CONVERT TO CHARACTER SET utf8;

As I explained in the original issue, do /not/ run a query like this. This would do an actual character set conversion, e.g. from Latin1 to UTF-8. Drupal has already been using UTF-8 data, we simply didn't tell MySQL about it (it thought it was e.g. Latin 1 data). Example: You had the character 'é' (Unicode U+E9) in a node. Its UTF-8 representation is (in hexadecimal bytes) "C3 A9". If the database character set was Latin1, then MySQL thought this was 2 characters, because in Latin1 each byte is one character. So, if you do a character set conversion, you would end up with the UTF-8 encoding for character C3 followed by the UTF-8 encoding for character A9, which is "C3 83 C2 A9". What we want MySQL instead to do is to realize the bytestream is already UTF-8 and see that the byte sequence "C3 A9" is a single character. The only way to do is to convert all columns to a binary type and then to UTF-8. This means no actual conversion is done, only re-interpretation: See: http://dev.mysql.com/doc/refman/4.1/en/charset-conversion.html Steven