Copying database tables in upgrade

I am upgrading a site from 1.38a to 1.51, having set up 1.51 in a new directory on the same server, and set up products, addons, etc. I now want to copy from the 1.38a database the tables related to customers and orders. Can't find the copy of instructions I have used previously with success to do this sort of thing.

Have I got this process right?:

in phpMyadmin

• truncate table 'customers' (for example) in the 1.51 database
• select the table 'customers' in the 1.3a database in phpMyadmin left column
• under 'Operations' 'Copy table to' the '1.51 database.customers' table with 'Data only' selected.

and do that for all tables I need to copy.

Do I then need to do a database upgrade using /install_zc?

Any clarification at all? I have spent hours revising and updating product information details on over 15 products, and renamed images, etc., to tidy up the new site. So I don't want to import the complete database.

godt:

Any clarification at all? I have spent hours revising and updating product information details on over 15 products, and renamed images, etc., to tidy up the new site. So I don't want to import the complete database.
Unfortunately this is exactly what you MUST do if you want the customer and order data brought across. You can always do a "backup" of your TEST db (1.5.x), "export" the changed product data (using something like EasyPopulate on 1.5.x), restore the LIVE db (1.3.8) over the TEST db (1.5.x), run the db upgrade, and "import" just the saved "product" data....

This should work unless you have changed product IDs or attribute IDs... I'd make sure you make plenty of database backups to make sure nothing is lost if something does go wrong...

See this article for more details on upgrading Zen Cart (especially step c under "how do I keep my live store running")

lhungil:

Unfortunately this is exactly what you MUST do if you want the customer and order data brought across. You can always do a "backup" of your TEST db (1.5.x), "export" the changed product data (using something like EasyPopulate on 1.5.x), restore the LIVE db (1.3.8) over the TEST db (1.5.x), run the db upgrade, and "import" just the saved "product" data....

This should work unless you have changed product IDs or attribute IDs... I'd make sure you make plenty of database backups to make sure nothing is lost if something does go wrong...

See this article for more details on upgrading Zen Cart (especially step c under "how do I keep my live store running")

Thanks for your reply. Sorry, I meant over 1500 products. And I do have the extra issue in relation to Ceon SEO url's, in that I have edited them to reflect duplicates, incorrect spelling, etc. I have done this empty table and copy from old db before: when you say 'must do', why is that? What am I risking? If I can import the product data without risk, why not the customer data?

The database structure is not identical between 1.38 and 1.5x. So not a good idea to try to take data formatted for one version and try to simply "import" it into a different version of the database.

The dev team created an "upgrade database" script for a reason. Use it. This is the fastest and safest method. There are plenty of threads on the forums here with additional reasons not to copy stuff willy nilly (without massaging the data) between different versions of the database. Do a search if you want to read more.

What I said in my last post was export the changes you made to the products in your 1.5x database and after upgrading the 1.38 dayabase to 1.5x, then you can import your 1.5x structured data for products / attributes / options into the now 1.5x database containing all your old data. I never said you can safely take data exported from 1.38 and import it directly into a 1.5x database (without heavy massaging). Also make sure you understand the caveats mentioned in my last post.

lhungil:

The database structure is not identical between 1.38 and 1.5x. So not a good idea to try to take data formatted for one version and try to simply "import" it into a different version of the database.

The dev team created an "upgrade database" script for a reason. Use it. This is the fastest and safest method. There are plenty of threads on the forums here with additional reasons not to copy stuff willy nilly (without massaging the data) between different versions of the database. Do a search if you want to read more.

What I said in my last post was export the changes you made to the products in your 1.5x database and after upgrading the 1.38 dayabase to 1.5x, then you can import your 1.5x structured data for products / attributes / options into the now 1.5x database containing all your old data. I never said you can safely take data exported from 1.38 and import it directly into a 1.5x database (without heavy massaging). Also make sure you understand the caveats mentioned in my last post.

Yes, thank you again. I understood your point about importing data, and my question - a bit rhetorical - was to do with whether there was something integral to customer related tables as opposed to product related tables. A look through phpMyAdmin revealed the difference between databases related to utf8. At which point, I got it.

Found the utf8 conversion thing, and I am thinking it is worth importing the 1.3.8 tables and then running the converter, before I go back to square one. And bang my head against the wall.

Thanks again for your reply, and your thoughts.

No problem. Just wanted to make sure I was clear. It has been awhile since I have looked at the 1.38 version of the database... But I seem to remember some changes to fields as well...

Collation differences can be fun... In Zen Cart mostly this affects the fields with text... But also any define pages... For the db you can always export using phpMyAdmin after the db upgrade (storing just data using UTF8 - the option shows up in my copy of phpMyAdmin anyways). Then try one of the tools to convert to UTF8.

Worst case once all the table collations are changed to UTF8, one can then fallback to truncating the affected tables and importing the saved data if necessary... Ugly and hopefully not needed, but can't hurt to have another intermediate backup of sorts.

For the define pages, notepad+ comes in handy. There are a few posts on here about exactly which encoding for these text pages is needed... Cannot remember the correct encoding off the top of my head...

Forgot to mention this earlier, and you may already know... If the table prefixes differ between your 1.38 to 1.5x install... You may need to do some additional massaging as well...

lhungil:

Worst case once all the table collations are changed to UTF8, one can then fallback to truncating the affected tables and importing the saved data if necessary... Ugly and hopefully not needed, but can't hurt to have another intermediate backup of sorts.

For the define pages, notepad+ comes in handy. There are a few posts on here about exactly which encoding for these text pages is needed... Cannot remember the correct encoding off the top of my head...

I like fallback positions! Dr Byte has information on text page encoding in the readme file to his utf8 converter.

I'm not inclined to live dangerously, but I'm thinking to truncate the appropriate tables in the 1.51 db, import the non-utf8 data from the 1.38 db, and run the converter. I suppose it could become a catherine wheel situation...

godt:

I like fallback positions! Dr Byte has information on text page encoding in the readme file to his utf8 converter.

I'm not inclined to live dangerously, but I'm thinking to truncate the appropriate tables in the 1.51 db, import the non-utf8 data from the 1.38 db, and run the converter. I suppose it could become a catherine wheel situation...

Personally? I would have made a backup of my current 1.3.8 db, did an upgrade on the database through a clean 1.5.1 install/location, then backed up the new database, to be taken to the new location. Restored the old 1.3.8 db. then gone to work on the new database with backing up the current 1.5.1 database in a way that I could modify where those records would be restored (to prevent duplicates) and then "merged" the two. But that's just me and how I understood the situation...

mc12345678:

Personally? I would have made a backup of my current 1.3.8 db, did an upgrade on the database through a clean 1.5.1 install/location, then backed up the new database, to be taken to the new location. Restored the old 1.3.8 db. then gone to work on the new database with backing up the current 1.5.1 database in a way that I could modify where those records would be restored (to prevent duplicates) and then "merged" the two. But that's just me and how I understood the situation...

Fantastic! I myself had that thought in the dead of night, and came here to ask if that was the better path: drop the existing 1.5 database tables, import a copy of the 1.38, do an upgrade, then copy the newly upgraded customer tables to the original 1.5 database. Less angst, I suspect.

Thanks again. Much appreciated.

godt:

Fantastic! I myself had that thought in the dead of night, and came here to ask if that was the better path: drop the existing 1.5 database tables, import a copy of the 1.38, do an upgrade, then copy the newly upgraded customer tables to the original 1.5 database. Less angst, I suspect.

Thanks again. Much appreciated.

Hold on, I think were talking about two different things. What I was suggesting is a process like this:

1. Backup the 1.3.8 database
2. Install 1.5.1 in a different directory than your current version, including the install directory
3. Copy the configure.php files over to the new directory (updating the path(s) as applicable in those files)
4. Run the install from the new directory and have it update your database.
5. Backup the database for upload to the "new" store
6. Restore your 1.3.8 database
7. In the new database, backup the data (sounded like there was already work done)
8. Upload the "old" database to the new site
9. Restore the records needed on the new database.

This is different than what I understood from above, unless when you meant dro the 1.5.0 database, you really meant that all of the tables would be removed. In that case, a very similar approach, but all updating would be done on the new database/install and your current. 1.3.8 would be left untouched.