Can't migrate test installation to live database

[HeleneWallis]

Has something changed in 1.57 that prevents two installations of Zencart from using the same database? This will be the third time over a six-year period that I've moved a test install to the live database, and I had no problems the first two times. I was using 1.55 both of those times and changed the two configure.php files without any problems. This time, I either get the "Can't open database" error message, or just a blank screen on both the store and the admin sides.

I'm aware that a blank screen generally means some php syntax error but I've looked at these two files until my eyes have crossed and don't see anything wrong. For once I remembered to check the error logs before asking here, and there are no error entries for today. I also actually remembered to set the ftp program to transfer text instead of binary. So there shouldn't be any hidden characters in the files. I was careful not to confuse the store configure file with the admin configure file. I'm out of ideas.

Live installation: https://www.newnaturalsonline.com
Test installation: https://www.zentest.newnaturalsonline.com

Thanks for any suggestions.

[mc12345678]

Couple of unexplained pieces of information...

Two installs using the same database? A ZC 1.5.7 install expects the database being accessed to have a different "configuration" than any previous version. (basically 1.5.7 has modified the database as compared to say 1.5.6 or any previous version.) So... to be sure we are talking about the same thing, do you mean that your 1.5.7 is pointing to exactly the same database (including DB_PREFIX) as the earlier version? If so, one of the two is not going to work correctly. Either the 1.5.7 because it hasn't been updated for 1.5.7 or the earlier version because the database has been updated and information *may* not be located where expected. As far as 1.5.7 to previous versions this is likely to be seen where ez-pages are concerned because those have been made multilingual and required some rearranging of information, tables, etc...

Now, if you mean that two stores reference the same database but both have different DB_PREFIX values, then yes that is possible. Usually the issue with "changing" the includes/configure.php file is that it hasn't been made writeable before attempting to save changes.

Now, as far as the blank screen without debug log, that is possible if the problem is really a php parsing error instead of some of the other "generic" issues. I don't have a great example, but I know that sometimes if I am not paying complete attention, I might leave out a backslash at the end of one of the paths, or in some sort of copy and paste a back quote gets used instead of a single quote or some other random mistake.

You could post the content of your includes/configure.php changing pertinent information to "protect the innocent". Exact letters are not necessarily as important to those here as is the format, quotes, slashes, and the like. Please obscure/obfuscate password/paths of concern, but be consistent with whatever you do and don't make up a line/quoted text ending that isn't in your version.

All that said though... if the standard upgrade by rebuild process were used, then the software would create the necessary configure files and there wouldn't be an issue such as this.

Could also help by posting both the "old" and the "new" includes/configure.php files and explaining why a difference exists between the two (e.g. This path is different because it points to the sub-domain of the test install.)

Also, it may be of assistance (maybe) to identify in a password type field if there are special characters involved (single quote, greater than, less than, ampersand, etc...)

To assist really I think it comes down to providing more information, even if it all seems to blur together at this point.

[HeleneWallis]

Couple of unexplained pieces of information...

Two installs using the same database? A ZC 1.5.7 install expects the database being accessed to have a different "configuration" than any previous version. (basically 1.5.7 has modified the database as compared to say 1.5.6 or any previous version.) So... to be sure we are talking about the same thing, do you mean that your 1.5.7 is pointing to exactly the same database (including DB_PREFIX) as the earlier version? If so, one of the two is not going to work correctly. Either the 1.5.7 because it hasn't been updated for 1.5.7 or the earlier version because the database has been updated and information *may* not be located where expected. As far as 1.5.7 to previous versions this is likely to be seen where ez-pages are concerned because those have been made multilingual and required some rearranging of information, tables, etc...

Now, if you mean that two stores reference the same database but both have different DB_PREFIX values, then yes that is possible. Usually the issue with "changing" the includes/configure.php file is that it hasn't been made writeable before attempting to save changes.

Now, as far as the blank screen without debug log, that is possible if the problem is really a php parsing error instead of some of the other "generic" issues. I don't have a great example, but I know that sometimes if I am not paying complete attention, I might leave out a backslash at the end of one of the paths, or in some sort of copy and paste a back quote gets used instead of a single quote or some other random mistake.

You could post the content of your includes/configure.php changing pertinent information to "protect the innocent". Exact letters are not necessarily as important to those here as is the format, quotes, slashes, and the like. Please obscure/obfuscate password/paths of concern, but be consistent with whatever you do and don't make up a line/quoted text ending that isn't in your version.

All that said though... if the standard upgrade by rebuild process were used, then the software would create the necessary configure files and there wouldn't be an issue such as this.

Could also help by posting both the "old" and the "new" includes/configure.php files and explaining why a difference exists between the two (e.g. This path is different because it points to the sub-domain of the test install.)

Also, it may be of assistance (maybe) to identify in a password type field if there are special characters involved (single quote, greater than, less than, ampersand, etc...)

To assist really I think it comes down to providing more information, even if it all seems to blur together at this point.

No, it doesn't all seem to blur together. That's exactly what I needed to know. I did not realize that the database configuration had changed, though I was beginning to wonder. I assumed that my speculation must not be correct, since now I'm wondering how one can upgrade to 1.57 at all without losing all the current information. I take it this means all my customers will have to create new accounts and will lose all their existing order information. And it means that I'll have to maintain the existing installation somewhere in order to answer questions about previous orders. I hate it when a company does that and I can't see my order history any more.

I know how to make a file writable, and did so in order to make the changes (and changed it back afterward). And I know that php syntax errors generally do not trigger an error log message. I mentioned that only to make it clear that I had checked the error log, since I had such a bad habit of forgetting that in the past, and asking questions here that would have been answered simply by checking the log. I will find the syntax error eventually. The real problem was being unable to access the existing database. I'll go back and read through migrating to 1.57 again. I had assumed it wouldn't be significantly different than the two previous times I had created a new website for the same company with 1.55.

Thanks for the information.

[swguy]

If you are changing version numbers (not letter, but numbers) like 155->157, you should assume there will be database schema changes and that you will need to run zc_install to get the database updated. Within a version where only letters are changed (157a->157c, for example), by tradition there is no database change done.

If you ever need to drill in for greater specificity, the database schema for each version is captured in the documentation:

https://docs.zen-cart.com/dev/schema/

[mc12345678]

To add to what swguy has stated and in relation to your previous post: No, once the site is upgraded, there is not a need for customers to redo everything and for the sole purpose of looking up history you do not need to maintain some separate version. (Backups are good to keep, but not so that a customer can ask about their history.)

This is covered through the upgrade process which is at least in part discussed in one or more of the references within the following doc: https://docs.zen-cart.com/user/upgrading/

[HeleneWallis]

If you are changing version numbers (not letter, but numbers) like 155->157, you should assume there will be database schema changes and that you will need to run zc_install to get the database updated. Within a version where only letters are changed (157a->157c, for example), by tradition there is no database change done.

If you ever need to drill in for greater specificity, the database schema for each version is captured in the documentation:

https://docs.zen-cart.com/dev/schema/

Thanks, I will take a close look at that.

[HeleneWallis]

To add to what swguy has stated and in relation to your previous post: No, once the site is upgraded, there is not a need for customers to redo everything and for the sole purpose of looking up history you do not need to maintain some separate version. (Backups are good to keep, but not so that a customer can ask about their history.)

This is covered through the upgrade process which is at least in part discussed in one or more of the references within the following doc: https://docs.zen-cart.com/user/upgrading/

Thank you, that's reassuring. I've already done 95% of what's covered in the docs about upgrading--set up a test version on a local server, moved it to a test directory on my domain, installed all the plug-ins I'm currently using, redid all the customization I had added to our current installation. All that was left to do, I thought, was to check it out with the live database and make sure all my product descriptions looked okay in the new template. I had hoped to see everything working in a live environment before I shut the website down and did the actual transfer, but I see that I won't be able to do that. Oh well. Thanks for your help.

[mc12345678]

Thank you, that's reassuring. I've already done 95% of what's covered in the docs about upgrading--set up a test version on a local server, moved it to a test directory on my domain, installed all the plug-ins I'm currently using, redid all the customization I had added to our current installation. All that was left to do, I thought, was to check it out with the live database and make sure all my product descriptions looked okay in the new template. I had hoped to see everything working in a live environment before I shut the website down and did the actual transfer, but I see that I won't be able to do that. Oh well. Thanks for your help.

"Ideally" you should generally still be able to do all that *and* test the process on your live server without taking down your existing site. It sounds like the difference missing is that on your live server you create an additional database to which you can "temporarily" copy the database of your live site to see how successful upgrading that copy will be. From there, working out what other actions are necessary.

Alternatively, all of the database tables in your live database could be copied to include a prefix that would be entered as your DB_PREFIX. That would allow you to use the same database, but two distinct sets of tables...

So I opened with "ideally". Your host should most definitely as in expected in operation to support having a second database WITHOUT any difficulty nor additional cost.

[swguy]

To add to what swguy has stated and in relation to your previous post: No, once the site is upgraded, there is not a need for customers to redo everything and for the sole purpose of looking up history you do not need to maintain some separate version.

When you run zc_install, just BE SURE to hit the UPGRADE button (not the CLEAN INSTALL button).

https://docs.zen-cart.com/user/upgra...er_no_upgrade/

[HeleneWallis]

"Ideally" you should generally still be able to do all that *and* test the process on your live server without taking down your existing site. It sounds like the difference missing is that on your live server you create an additional database to which you can "temporarily" copy the database of your live site to see how successful upgrading that copy will be. From there, working out what other actions are necessary.

Alternatively, all of the database tables in your live database could be copied to include a prefix that would be entered as your DB_PREFIX. That would allow you to use the same database, but two distinct sets of tables...

So I opened with "ideally". Your host should most definitely as in expected in operation to support having a second database WITHOUT any difficulty nor additional cost.

Creating a temporary copy of the live database and testing the upgrade on that is the ideal solution, thanks.