catch-22 after moving to a new server

This post follows my 'resolving' post for the post titled "An apparent conflict with my Apache configuration". Attempting to move a correctly performing Zen Cart site from a hosted server (necessitated by 1and1's inadequate PHP memory allocation for hosted sites), I encounter the following bind. If I follow the faq instructions as faithfully as I can construe for moving a site from one server to another I get a perfectly mirrored site on the virtual server. Every product with every bit of graphics and text displays correctly. The ordering process performs correctly through the final 'thank you' after Paypal payment. But the site's frozen in that state because I cannot activate the administration process. As I've described voluminously in a previous post, the admin login id/password prompt displays but when 'submitted' execution vanishes in every way discernable from the console. Debugging the login file execution, I find that execution flows through the entire table and everything that's supposed to be sent elsewhere does so. But having done so, execution vanishes as discernable from the console.

However, one process component alone doesn't make a bind. The bind is that if I install from scratch on the virtual server, using the database with the correctly performing hosted sites voluminous categorization and product description records and also update the files from the correctly performing hosted site, using the protocols specified in the faq, I get a site on the virtual server which does not incorporate the information on the database. The administration utility works fine, but I'm forced to start entering categories and products from scratch. That's not going to happen.

So, there's the catch-22. Any omniscience on this issue out there, please.

Oops! There's no need to reply to this until I correct an installation error, probably in two days. When I went through the fresh install process I used the pre-existing database that had all the correct categories and product information that had displayed correctly on the installation that worked perfectly except inaccessibility of the admin utility. I didn't (1) install on a fresh database, (2) drop its table, (3) import the old database that I had previously exported to my client hard drive. Now I'll correct that oversight. However, if there's some way to make the new install aware that its categories and product descriptions are already available on its database -without having to go through the export, drop, import cycle- I'd appreciate knowing that procedure.

Oops postscript. However, when I do repeat the canonical procedure, I will repeat the installation described previously which performed perfectly on the virtual server except that the admin utility would not work; hence the aforementioned bind.

Wow, I know I can be confusing, but...

Are you saying that after creating a new site with fresh downloads, that when the database at that new site is wiped clean and the old database is imported, everything stops working on the admin side?

Before I answer, let me be absolutely certain that that's what I did initially. Sometime in the next 24 hours I'm repeating the procedure according to your faq instructions "I want to move my Zen Cart installation to another host or a different server". This has to be done and it will be done. My corporation website has linked to an "eStore renovating" for too long. In the mean time, God Bless Jeff Bezos.

Zen cart installed with one glitch. At the time of the last post my belief was that the otherwise correctly functioning installation's failure to detect the product information in the database implied I had to go through a completely fresh installation. I had attempted to skip some steps by installing using a completely inventoried database from a correctly functioning hosted site. After the post though, it occurred to me that although the FAQ specified a "new" database at installation, the db was only an "old" database from my perspective. The freshly installed program was apparently oblivious to that history; i.e., it was "new" from the new installation's perspective. Therefore, it would be consistent with the FAQ instructions to "drop" the db's files and import the files exported from the db used on the hosted site. And voila! The site opened with everything appearing correctly and performing correctly. The admin utility displayed all the product information in the database. The one glitch is that the products don't display on the launch page. They should display beneath the "manufacturer" and "alphabetic" selectors, but that space is blank. The cause apparently is that I did not upload all of the old files over the new because I was afraid of losing the installation functionality that I had struggled for weeks to restore. Instead, I incrementally replaced new files which are clearly involved in product display with their old counterparts. So that's where this is at. I'm beyond seeing light at the end of the tunnel and have begun to emerge.