Your database appears to need patching to a higher level.

[kobra]

I've followed a few threads over the last 18 hours and found no clear, effective answer to the question of correcting the CHARSET and DB issue.

As latin1_general_ci is the default and yours is utf8 - - it was altered by something

To continue using the utf8 DB I reiterate - -

Do the following before running the zc_install to upgrade the DB

change the DB_CHARSET in /zc_install/includes/installer_params.php to 'utf8' before using zc_install.

[worldmaker]

As latin1_general_ci is the default and yours is utf8 - - it was altered by something

To continue using the utf8 DB I reiterate - -

Do the following before running the zc_install to upgrade the DB

change the DB_CHARSET in /zc_install/includes/installer_params.php to 'utf8' before using zc_install.

You didn't read my post - I had already made that change in advance of running the upgrade.

Then received the Error message: "1253 COLLATION 'utf8_general_ci' ..."

Then the internal, Admin, message regarding the need to patch the database.

I am now seeking clarification and answers to resolve the latter issue - how to resolve the patch issue given that my databases are in utf8 format.

[worldmaker]

I appear to have solved the problem, thus:-

1 . Using my test database I dropped all the tables, and cleared it for a fresh start on solving this issue.

2 . I copied then edited the copy of the .sql file from the master store database - the export file. Edited using simple text editor, not word processor. And saved back in simple text format as a .sql file.

3 . In this editing I replaced any references made to any character set other than "latin1_general_ci".

4 . Saved this edited sql file under new name.

5 . Used this new, edited .sql file as the import source for the new database.

6 . During the import I carefully selected the "latin1" character set for the process (at least I think that's what that button meant!), because the service provider defaults to "utf8".

7 . Returned to zc_install/includes/installer_params.php and edited out the "utf8" and restored the "latin1".

8 . Returned through browser to begin installation again.

9 . After a little hiccup or two (had to make configure.php file writable), and carefully going through the steps to upgrade - everything went smoothly.

Conclusion
So far, so good.

Back into the Admin section.
No RED WARNING MESSAGES.
No other alerts that I can see on a preliminary glance.

Will now have to check that all the products, etc., etc., are back in place, to reinstall the payment and shipping modules, add others and see what happens.

I'm sure if something goes wrong you'll be hearing from me again, but on this issue - SOLVED IT!

[DrByte]

3 . In this editing I replaced any references made to any character set other than "latin1_general_ci".

If your store's products, categories, customers, ez-pages, etc, use ANY non-english-characters, then DO NOT DO THAT, else you'll find all your database content will contain odd annoying symbols where those characters were originally found.

If your database contains strictly english-only characters and no extended-character symbols, (ie: not even TM or (c) symbols), then the raw data-hacking approach you described may work if executed perfectly.

USE WITH EXTREME CAUTION!!!!

[worldmaker]

Thanks for the addition Doc.

It did cross my mind briefly, to warn everyone but it's been a long couple of days and things are getting blurry around here (it's now past midnight) and I have to assume a little common sense out there, don't I, please?

I'm sure to find a problem later, especially with extended characters, but for now, this worked on my test site.

[stuffdone]

Since I am not a programmer I have decided to not upgrade in the hopes that a future release will contain a more developed upgrade path that includes a solution to this.

I still don't understand why there is this discrepancy since I never did anything to change from UTF8 prior to the upgrades..what ever it is before the upgrades was the default from the original Zen installation. I always use the defaults for everything other than the obvious site-specifics like the DB info and admin information.

Someone kept insisting I changed something related to the UTF8 but I would not know how nor would I have a reason to do so. If there is a method to change that in the prior version then the upgrade instructions need to warn users and add a 4th step to go to the CP and make sure the utf8 is changed prior to trying the upgrade.

[stuffdone]

SUGGESTION

Can someone who understands all of this write a new Upgrade instruction to include this issue and how to avoid it from the start?

It does not appear to be either isolated or rare that others are finding the same errors when trying to upgrade. It seems more logical to prevent others from wading through dozens of posts to just include the necessary steps as part of the documentation to do the upgrade.

If I understood this myself I'd try to post it but I am confused which may have to do with my advancing years and desire for a nap

[kobra]

I always use the defaults for everything

You might BUT it may be a mysql default set by your host to only use utf8
Something then to open with your host

[worldmaker]

SUGGESTION

Can someone who understands all of this write a new Upgrade instruction to include this issue and how to avoid it from the start?

...

If I understood this myself I'd try to post it but I am confused which may have to do with my advancing years and desire for a nap

Yes, so many comments on this subject floating around, but our hard-working programmers, all volunteers, can't be everywhere at once. It has crossed my mind to write something but the best I could do was the previous note offering one solution and how to do it, I haven't the time for more (struggling with other problems and relearning everything).

However, I did upload my new cart with the edited (export).sql file as I noted above, only this time I tested editing the (export).sql (that's the file exported from the working source database) for "utf8" instead of "latin1" and switched the "zc_install/includes/installer_params.php" to favour "utf8" and had no trouble upgrading at all. This makes my db ready for the next major upgrade when the cart shifts to the new improved model.

Most of it can be done in a plain text editor, if you're language pack is not radically off the mainstream.

As DrByte recommends, this ought to be done with GREAT CARE, and I suggest creating a new separate test database and site first before running a full upgrade to your new cart. And editing a copy of your .sql files not the original export.

[DrByte]

You could try editing /zc_install/includes/functions/general.php on line 150, changing this:

              $collateSuffix = ' COLLATE ' . DB_CHARSET . '_general_ci';

to this:

              $collateSuffix = (strtoupper($param[3]) == 'AS' || (isset($param[6]) && strtoupper($param[6]) == 'AS')) ? '' : ' COLLATE ' . DB_CHARSET . '_general_ci';

... and see if that gets around the odd collation error message you were seeing on the CREATE TABLE step.