install freezes at "Loading Character Set specific data 59%"

Doing a fresh install of v1.5.5 (in process of upgrade) and the install process froze on the screen where it is "loading character set specific data". Should I simply refresh the page, delete everything and start over or ??

Have done many installs but this new version is not as familiar as the old install.

Help!

It's rare for that to happen, but if it does I'd first just reload the page and fill in the DB info again, and let it do its install over. Or go back one page and go from there.

If it's halting due to some sort of error, it's most likely logged in the /logs/ folder in zcInstall-DEBUG-xxxxxx.log files.

It might be a result of incomplete files from a bad FTP upload, too.

Well, I tried starting over with the install and running it again. This time it froze on the same screen but at 64%. Maybe if I try it a few more times, it will finish that step! :)

Ok, I'm at a total loss here. Third time running the install and it freezes now at 58%. I can see no data has been added to the database and there is no DEBUG log file (there are other log files that don't say DEBUG, though).

Guess the next step will be to completely delete all the ZC files and the database and start over. :(

By the time it's at the stage of loading "character set specific data", it's already built all the tables, and is starting to fill some of them with basic data such as country names etc.

So, if your database is truly still empty at that point, then that suggests to me you're checking the wrong database when trying to debug it.

Hmmm... maybe I just didn't look in enough tables, but I'm very sure I was looking at the correct database in phpMyAdmin. I will have to come back to this tomorrow as I ran out of time to troubleshoot this install. Thought it would just take a few minutes but an hour later, I am out of time. :(

Ok, I restarted this project today. I completely deleted the previous test store directory (in Filezilla) and I completely deleted the database I created yesterday. I even redownloaded the 1.5.5 zip file from SourceForge. Unfortunately, I'm still stalling out in "loading character set specific data." Comparing the database data to the mysql_utf8.sql file in the install folder, I can see that the countries were added except the last one and no zones have been added. Unlike yesterday, this time a DEBUG log file was generated and it has 14 lines that all say:

[13-Apr-2016 10:45:59 America/New_York] PHP Warning:  mysqli_connect(): (HY000/2002): No such file or directory in /homepages/PATH_TO_STORE/includes/classes/db/mysql/query_factory.php on line 102

In case any of this is pertinent to the problem, here is as much information as I can collect about the server and site:

Host: 1&1
PHP version: 5.5.34
MYSQL version: 5.5

Thanks, DrByte for your previous assistance on this. Is there anything else that would shed light on this issue?

On closer inspection, I'm not sure that debug line is related to the problem of running the [COLOR=#333333]mysql_utf8.sql file. The time stamp on that file is earlier than the last zcInstallLog file that ends with:

Apr 13 2016 10:49 -- General
processing file /homepages/22/d250293540/htdocs/155_store_upgrade/zc_install/sql/install/mysql_utf8.sql

Not knowing exactly how this new installation works, it sure looks to me like the process partially completes the SQL statements in that file but doesn't finish and doesn't do anything further.

Hope there is some way to complete this install on this server. The host is forcing my client to upgrade to php 7 soon (or pay extra money) and I'm aware that only zc 1.5.5 works with php 7.

earmsby:

[13-Apr-2016 10:45:59 America/New_York] PHP Warning: mysqli_connect(): (HY000/2002): No such file or directory

While the wording is strange, that combination of error number and error message usually means it can't connect to the database. And often it's  because of mismatches in the way the server's name-resolution is working.
Sometimes changing the DB_SERVER from 'localhost' to '127.0.0.1' is enough to fix it.

It could be that you were getting those errors before zc_install asked you for the db details (and thus the errors are just a byproduct of the system-inspection probing that zc_install does) ... and then those errors stopped after you gave it your real db details. In that case those errors can be ignored.

earmsby:

On closer inspection, I'm not sure that debug line is related to the problem of running the [COLOR=#333333]mysql_utf8.sql file. The time stamp on that file is earlier than the last zcInstallLog file that ends with:

Apr 13 2016 10:49 -- General
processing file /homepages/22/d250293540/htdocs/155_store_upgrade/zc_install/sql/install/mysql_utf8.sql

Not knowing exactly how this new installation works, it sure looks to me like the process partially completes the SQL statements in that file but doesn't finish and doesn't do anything further.
You are correct in your understanding of the flow.

I'm still puzzled about why it's halting, and at different points each time.

Hi

Can you provide info regarding your server setup

e.g. php version, mysql version etc.

your admin/server_info.php will provide this info

Or put a file on your server like this:
filename: phpinfo.php```

Could it have anything to do with collation? As far as I can tell from everything I can see in phpMyAdmin the database and tables use UTF, but is it possible that something somewhere else is latin-1 and that is causing a problem? I guess if that were the problem none of the UTF-8 data would be written.

Next, I wonder if the issue has something to do with 1&1. I might try to replicate this install on another server just to see if I get a different result or if the same thing happens.

Meanwhile, if you can think of any other possible reason or possible place for me to look for info that would shed light on the problem, I'd be appreciative.

I'm guessing no one else has reported any problem like this?

Thanks for your help!

Thanks Wilt, I think I did give the php and mysql versions above. :)

[QUOTE=earmsby;1308471]Could it have anything to do with collation? As far as I can tell from everything I can see in phpMyAdmin the database and tables use UTF, but is it possible that something somewhere else is latin-1 and that is causing a problem? I guess if that were the problem none of the UTF-8 data would be written.
[/code]
For a fresh install I don't see how collation matters in this context.

earmsby:

Next, I wonder if the issue has something to do with 1&1. I might try to replicate this install on another server just to see if I get a different result or if the same thing happens.Perhaps.

earmsby:

I'm guessing no one else has reported any problem like this?Nobody.
Of the hundreds of installs I've done, I've not encountered it failing like this, at least not without logging a "why" in the logs.

Are you trying to enable HTTPS from the get-go? 1&1 (shared-server accounts) currently has some "issues" like no support for TLS 1.2 that could be getting in the way.

lat9:

Are you trying to enable HTTPS from the get-go? 1&1 (shared-server accounts) currently has some "issues" like no support for TLS 1.2 that could be getting in the way.

Yes, I was using HTTPS from the start because the current live site does. I thought you had to use https to even be able to log into the admin section at all. I guess I try the process again without it just to see what happens and if that makes a difference.

earmsby:

I guess I can try the process again without it just to see what happens and if that makes a difference.

Tried it without HTTPS at all and still froze adding UTF data.

Next step is to try it on a different server. I'm continuing to suspect it's an issue with 1&1. They lock down a number of things that I have found irritating to get around (like no remote MYSQL access so I can only work with the database through their myphpadmin portal).

earmsby:

Tried it without HTTPS at all and still froze adding UTF data.

Next step is to try it on a different server. I'm continuing to suspect it's an issue with 1&1. They lock down a number of things that I have found irritating to get around (like no remote MYSQL access so I can only work with the database through their myphpadmin portal).

Ok, I tried running pretty much the exact same install on a different server (BlueHost) this time and the database step ran in a matter of seconds with no problem. So, I think that means I will need to ask the client to put in a support ticket with 1&1. Is there anything I would want to advise him to ask them to look at?

The ironic thing here is that 1&1 is basically forcing him to upgrade to ZC 1.5.5 because of their forced upgrade to php7 in May. But if some setting on their server is tripping this up and preventing him from doing this upgrade then they're planning to charge him extra money for staying on php 5.x :shocking:

If you install/upgrade at another host (Bluehost) then you should be able to move this fileset and DB to 1&1 for your client
Basically follow this FAQ
https://www.zen-cart.com/content.php?142-i-want-to-move-my-zen-cart-installation-to-another-host-or-a-different-server

kobra:

If you install/upgrade at another host (Bluehost) then you should be able to move this fileset and DB to 1&1 for your client
Basically follow this FAQ
https://www.zen-cart.com/content.php?142-i-want-to-move-my-zen-cart-installation-to-another-host-or-a-different-server

Perhaps, but 1&1 locks down their database servers pretty tightly and I've had a hard time doing dumps and restores. I'm almost ready to insist the client move to a new host or else find a new web developer. [exasperated...] Of course the client doesn't want to pay much to do "routine" things. ;)