en Jump to content
  • 0
musicmaster

Copy Shopdata: Script for copying shop content for upgrade

Question

The attached script copies the content (business data) of a shop from one installation of Prestashop to another. The products, orders, customers, etc of the new (usually freshly installed) shop will be completely replaced by those from the old shop while its configuration is maintained. Your customers can even keep their old passwords.

Prestashop updates regularly result in unstable situations. This instability is nearly always in the files or the configuration settings.In either case this script can be a solution as it leaves both behind. It is far superior to a csv export as that copies only a part of your data.

Copy_shopdata should be installed in the same directory as Prestools as it uses Prestools for authorization. It should be installed in the new shop, after which you fill in the database data of the old shop in copy_shopsdata's config file.

Copy_shopdata is meant to repair installations. You should leave the upgrade process to Prestashop.

Documentation is in the pdf file.

PS. Nearly any shop can be repaired and/or updated this way. If you are afraid to do it yourself you can hire me to do it for you.

PS-2. Some people have tried to use this tool for updating from 1.6.1 to 1.7. This is to some extent possible as the database structure is very similar. However, you should only update to 1.7.2 and use the PS updater for updating to 1.7.3. One problem is the security key (Rijndael) that is differently structured in 1.7. I don't know how to make that transition and doubt that it can be made at all. That means that you shouldn't copy the ps_employee* tables or adapt those keys. You may copy the ps_customer* tables but you will need to ask your customers to reset their passwords. However, copying product data is possible. Yet some adaptions are needed such as setting the "state" field in ps_product to "1".

copy_shopdata-v0.29.zip

Edited by musicmaster

Share this post


Link to post
Share on other sites

60 answers to this question

Recommended Posts

  • 0

There are some BUGs in the source code of these files...

1. I strongly recommend to use the same DataBase prefixes. (old shop and fresh shop). I had to update all these files manually inserting different prefixes.

2. There is difference between old language codes and new language codes... in ps_lang.

New PS 1.6 have language code for example de-de

Old PS 1.4 -> updated to 1.6 wiil have de language code...

3. some updates to copy_shopdata.php

 

line 62   for($i=0; $i < (sizeof($oldlangs)-1); $i++)

we should reduce count of iterations.

 

line 207  for($i=0; $i < (sizeof($oldlangs)-1); $i++)

same

Share this post


Link to post
Share on other sites
  • 0

Hi IceCool,

 

Thank you for your reaction:

 - ad 1: I am not sure what you mean. Did you change in copy_shopdata_config.php the setting for the old shop?

 

 - ad 2: I didn't find such problems working with a shop that originally was 1.4. PS update should take care of that.

 

 - ad 3: in line 62 it needs to compare all languages. If you compare "fr-en-it" with "fr-en-ru" you should get an error message.

 in line 207 you need to take into account the case where positions are exchanged. If you change "1=fr 2=en" to "1=en 2=fr" french will temporarily be copied to id 3 and you need a second copy operation to move it back to 2.

Share this post


Link to post
Share on other sites
  • 0

hey musicmaster,

 

Im trying to copy data from 1.6.1.2 to a fresh install of 1.6.1.3 but getting errors.

 

First error was involving accessories so I remove that from the list, then the next error shows.

13:49:04
1 old languages; 1 new languages. Language check ok.


address 5799 1

MySQL error 1045: Access denied for user '********'@'localhost' (using password: YES)
Generated by Query 'SELECT `id_address`,`id_country`,`id_state`,`id_customer`,`id_manufacturer`,`id_supplier`,`id_warehouse`,`alias`,`company`,`lastname`,`firstname`,`address1`,`address2`,`postcode`,`city`,`other`,`phone`,`phone_mobile`,`vat_number`,`dni`,`date_add`,`date_upd`,`active`,`deleted` INTO OUTFILE '/home/*******/public_html/newshop/*******/triple_edit/copy_shopdata_address.dtx' FROM ps_address' 

This script worked fine copying from an upgraded 1.6.1.2 to a fresh 1.6.1.2 so has code changed in 1.6.1.3 ?

 

UPDATE: I have just managed to update my live shop to 1.6.1.3, yet the script still wont copy from my live store to the fresh install.

 

Cheers

Ray

Edited by MerseyRay

Share this post


Link to post
Share on other sites
  • 0

Hi MerseyRay,

 

This is an "access denied" error. So it has nothing to do with the structure of the database.

 

The problem is in the second part of the command "INTO OUTFILE []copy_shopdata_address.dtx". On Unix servers this very often leads to an error that MySql is not allowed to write that (or any other) file. The immediate solution is to increase your rights. 

 

However, I am considering to remove the option in the script to move data between servers. It gives too much problems. The best way to work is to upgrade on your local computer (localhost) and then upload the files to the server.

Share this post


Link to post
Share on other sites
  • 0

Hi musicmaster,

I'm trying script copy_shopdata on my localhost installations - both 1.6.0.9 and I got stuck at the very beginning of copy process

 

1) old installation - I've downloaded my current installation 1.6.0.9 via FTP & exported database.sql and configured it to run localy (OS X, MAMP, Sequel Pro).

 

2) new installation - I've installed fresh installation same version 1.6.0.9 on my localhost, where I added subfolder "triple_edit" with its files, as well as script copy_shopdata files

13:45:32
1 old languages; 1 new languages. Language check ok.


accessory 1123 1
MySQL error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '-new.ps_accessory SELECT `id_product_1`,`id_product_2` FROM maclife-old.ps_acces' at line 1
Generated by Query 'INSERT INTO maclife-new.ps_accessory SELECT `id_product_1`,`id_product_2` FROM maclife-old.ps_accessory'

I've checked manual but I didn't find any useful information.

 

Could you please give me some advice, what should I check or revise. As I'm only basic user with some additional skills, I'm not very good in coding, syntax, etc.

 

Thanks for any advice.

Share this post


Link to post
Share on other sites
  • 0

I am not totally sure. But my guess is that the hyphens ("-") in the database names are the problem. They might be interpreted as "minus". The solution is to put the server names between backticks.I will have a look at it.

Share this post


Link to post
Share on other sites
  • 0

You've guessed right musicmaster.

 

The problem was in the name of database "maclife-old" was misinterpreted as maclife minus old.

 

I've changed it to "maclife_old" and everything looks ok.

 

Thanks for quick advice. ;)

Share this post


Link to post
Share on other sites
  • 0

Hi,

 

I have 1.6.1.2 running and have some database trouble and other problems. My features are messed up and I can't fix it nor I can't get back to a older state. Also i'm struggling too long with this site for almost a year.

So I'm busy creating a new shop with latest version of PS and want to have the products without features and attributes , customers, Categories and orders to import to new one and then recreate attributes and features. I mean I want only the necessary files back to the new site and build it module by module.

 

Then when finished and tested I want to switch over to that.

 

Is that posible to do. Or could someone help me with it? I'm willing to pay for it. I run it at my own server so I can give acces to SQL, BA, FTP and so on.

 

I hope someone can help me.

Thanks in advance.

 

Ed

Edited by Ed van der Meer

Share this post


Link to post
Share on other sites
  • 0

I have detected an error the table ps_product_lang is not generated correctly, it is created with the id_lang of the old DB, not with the id that corresponds to it in the new DB

Share this post


Link to post
Share on other sites
  • 0

Language transformation happens rather late in the code and depends on all the language tables being flagged as such.. Are you sure the script didn't break off somewhere in the middle? 

 

In older versions having a $startnum greater than zero meant the skipped tables were not considered for the language transformation. In the latest versions (several months already) this problem has been repaired.

 

If you believe it is something else please let me know. I am always open for opportunities to improve the script.

Edited by musicmaster

Share this post


Link to post
Share on other sites
  • 0
Hi,
I'm not sure If I'm the only one, but after downloading latest version v0.19 of script copy_shopdata it doesn't work properly.
 
I used previous versions multiple times and everything worked perfectly, but now after copy process the source (old one) database is corrupted and the new one is untouched.
 
I've tried to move data on localhost from PS1614 –> PS1614 or from PS1614 -> PS16110 with same bad results.
 

 

Thanks for any advice.

Share this post


Link to post
Share on other sites
  • 0

 

Hi,
I'm not sure If I'm the only one, but after downloading latest version v0.19 of script copy_shopdata it doesn't work properly.
 
I used previous versions multiple times and everything worked perfectly, but now after copy process the source (old one) database is corrupted and the new one is untouched.
 
I've tried to move data on localhost from PS1614 –> PS1614 or from PS1614 -> PS16110 with same bad results.
 

 

Thanks for any advice.

 

Hi Rudolfo,

 

I tried it for myself and concluded that the script didn't work when the prefix of the two shops differed. In the new version that I have uploaded that is repaired.

 

However, I can't see any sign of changes in the old shop so I am very puzzled by that aspect of your report. Are you sure you put the script with the new shop and entered the references for the old shop in the config file?

 

This time the script put me into the login loop on the new shop. So I can't yet evaluate it further. A good opportunity to finally solve that almost a decade old problem. Unfortunately I don't have much time at the moment so it will have to wait a bit.

 

Regards,

M.

Edited by musicmaster

Share this post


Link to post
Share on other sites
  • 0

Hi musicmaster,

 

results are the same with script v0.20.

 

Step by step 1.6.1.4 –> 1.6.1.4 (MAMP, Sequel Pro, macOS Sierra)

 

1) source data installed to root folder on localhost - language ID 2 (only one language active), database name: "1614old"

2) new installation PS 1614 installed to subfolder "1614" with database name "1614new", folder "prestools" with copy_shopdata files copied to "admin..." folder, localization (Slovak) imported and activated as ID 2, default language English ID 1 deactivated and erased

3) script started with .../1614/admin.../copy_shopdata.php

4) after whole process, source/old installation corrupted and the new one untouched, screenshot of localhost attached

 

Thanks

 

Sn_mka_obrazovky_2016_12_08_o_14_58_57_1

Edited by Rudolfo78

Share this post


Link to post
Share on other sites
  • 0

Hi Rudolfo,

 

Can you switch on the development mode in the old shop so that you can see what error that 500 error hides?

 

Can you export the database of the old shop before and after the copying and look for differences with a program like WinMerge?

 

Are you able to enter the backoffice of the shops after the copying? There may be some problem with .htaccess and the backoffice is not vulnerable to that as it doesn't redirect.

 

Regards,

M

Share this post


Link to post
Share on other sites
  • 0
Hi musicmaster,

 

beforehand I have one more question, whether is it ok to replace one file when I am copying copy_shopdata files to prestools folder or should I keep the original one?

 

Thanks,

R

Share this post


Link to post
Share on other sites
  • 0

Hi musicmaster,

 

Sorry for previous explanation. :) Mentioned "one file" is exim.php

 

Prestools folder contains it, as well as copy_shopdata folder contains it and as I know copy_shopdata files should be copyed to prestools folder. Right?

 

My question: Is it necessary to overwrite files exim.php or not?

 

Thanks,

R.

Edited by Rudolfo78

Share this post


Link to post
Share on other sites
  • 0

exim.php

 

Prestools folder contains it, as well as copy_shopdata folder contains it and as I know copy_shopdata files should be copyed to prestools folder. Right?

 

My question: Is it necessary to overwrite files exim.php or not?

 

Exim.php is irrelevant in this context. It doesn't matter what you do.

 

Regards,

M.

Share this post


Link to post
Share on other sites
  • 0

Hi master,

 

answers to your questions:

 

1) Development mode see attached screenshot

 

2) According to DiffMerge tool (which is similar to WinMerge), there are 199 changes between both SQL files old vs. new one - there is also significant difference in size of these files (11,8MB vs. 0,6MB)

 

3) I am not able to enter backoffice of old shop, new one works perfect but it is untouched (default data in products catalog etc.)

 

Any suggestions?

 

Thanks,

R.

 

Sn_mka_obrazovky_2016_12_09_o_11_25_21.p

Edited by Rudolfo78

Share this post


Link to post
Share on other sites
  • 0

Hi Rudolfo,

 

Strange, I don't know how to explain this.

 

First of all, 0.6mb is the size of the new shop's database. Even if you copied the business data from the new shop to the old shop you wouldn't arrive at this number as there are tables like ps_connections and ps_guest that usually are quite big and that are not changed by copy_shopdata.

 

The Prestashop exception suggests that your ps_shop table in the database is empty. Could you have a look?

 

Can you be more precise about not being able to enter the admin of the old shop? What is the message you get?

 

Regards,

M.

Share this post


Link to post
Share on other sites
  • 0

Hi master,

 

Yes ps_shop table is empty (see attached image 1)

 

Error message I've got after entering "localhost/admin..." in browser (see attached image 2)

 

Regards,

R.

 

Sn_mka_obrazovky_2016_12_09_o_13_16_41.p

Sn_mka_obrazovky_2016_12_09_o_13_15_55.p

Share this post


Link to post
Share on other sites
  • 0

 - Did you make any changes to the newest copy_shopdata_config.php beyond filling in the access data for the old shop?

 

 - Did you make any changes in the new shop before you started the copying?

 

 - if you mail a copy of your old shop to me (info@prestools.com) I will try it myself. I need only the database dump and the settings.inc.php file. The latter for the Ryndael keys. An export of the database after the copying would also be welcome (it would give me more insight of what is going on).

Share this post


Link to post
Share on other sites
  • 0

- I didn't make any other changes except for filling in the access data for the old shop.

 

- In the new shop I've only imported and activated new (Slovak) language and deactivated and erased default (English) language.

 

- I'll send you PM here shortly.

 

Regards,

R.

Share this post


Link to post
Share on other sites
  • 0

Fian

 

- I didn't make any other changes except for filling in the access data for the old shop.

 

- In the new shop I've only imported and activated new (Slovak) language and deactivated and erased default (English) language.

 

- I'll send you PM here shortly.

 

Regards,

R.

It turned out that approve.php of Prestools didn't handle the nested shop situation correctly. It included the Settings.inc.php of the shop in the root instead of the shop in the subdirectory under which it had been placed. As a consequence the old shop was also seen as the new shop and its tables were emptied. Things have now been repaired. I have also added an extra check for the case that the old and the new database are the same. In that case you will now get an error message and the script will stop.

 

Thanks,

M.

Edited by musicmaster

Share this post


Link to post
Share on other sites
  • 0

Can you advise if this script will work for me?

I want to upgrade my shop from 1.6.0.9 to latest version. I do not want to use the 1-click upgrade as it is the risk to end up with an unstable shop.

In the past when want to upgrade:

1 Installed new shop with the same version.

2 Deleted all records from newly installed shop database and imported database from the old shop.

3 Check if all working fine in the back and front office.

4 1-click upgrade of new installed shop to higher version 

5 If new version works fine switch domain (have one domain for tests) to newly upgraded shop.

 

Lately, is not working. Have errors server misconfiguration after import database from the old shop.

 

If your script can copy a database from live shop to newly installed shop in the same version (live shop leave intact)?

Share this post


Link to post
Share on other sites
  • 0

Can you advise if this script will work for me?

I want to upgrade my shop from 1.6.0.9 to latest version. I do not want to use the 1-click upgrade as it is the risk to end up with an unstable shop.

In the past when want to upgrade:

1 Installed new shop with the same version.

2 Deleted all records from newly installed shop database and imported database from the old shop.

3 Check if all working fine in the back and front office.

4 1-click upgrade of new installed shop to higher version 

5 If new version works fine switch domain (have one domain for tests) to newly upgraded shop.

 

Lately, is not working. Have errors server misconfiguration after import database from the old shop.

 

If your script can copy a database from live shop to newly installed shop in the same version (live shop leave intact)?

 

I don't know what to make from your procedure. It is my impression that instability is often not in the files but in the configuration part of the database. 

 

The big difference between my script and your procedure is that it copies only the "business data" tables of the database: products, orders, etc. It doesn't copy the configuration tables of the database (configuration, module, hook, etc). That means that the chance that the new system will be stable is much bigger. The price is that it will take a bit more work.

Share this post


Link to post
Share on other sites
  • 0

Hey MusicMaster:  So if I have a 1.6.1.12 old shop and a 1.6.1.12 new shop will it skip modifying the old store?  I would like to be able to run this pulling from a production install over to a fresh install.  Then install theme and extra mods in new shop.  Then run it again just before going LIVE to grab new customers and orders accumulated since the first run.

 

Think it will work?  Backups will be made of course.

 

Wil

Edited by A-Z Hosting

Share this post


Link to post
Share on other sites
  • 0

 - yes, the old shop will not be changed.

 - yes, you can run a last minute run to include the latest orders, etc.

 

Of course you are encouraged to have an extra run somewhere half way your project. Being familiar with how it works is the best way to avoid surprises.

Share this post


Link to post
Share on other sites
  • 0

 - yes, the old shop will not be changed.

 - yes, you can run a last minute run to include the latest orders, etc.

 

Of course you are encouraged to have an extra run somewhere half way your project. Being familiar with how it works is the best way to avoid surprises.

 

Good idea thanks. One more question while I have your attention.  Once I have things as I want them do you have any ideas on jumping to 1.7.1.0?  Will it still ignore the old and just bring over the updated data?  Or should I upgrade the old, upgrade the new, and then bring over the updated data?

 

Wil

Share this post


Link to post
Share on other sites
  • 0

Always upgrade Prestashop to the same version. The databases of 1.6.1.12 and 1.7.1 are very similar. So it might work - at least at first sight. But you have no guarantee that the minor differences that are present will not cause problems somewhere in the future.

Share this post


Link to post
Share on other sites
  • 0

That's kind of what I figured on the side of caution. Just wanted to confirm. Thanks for the scripts these have been much needed.  You ever thought of turning into a full module? Have the settings all configurable from the destination store side? Adding a few other parameters like "skip old store upgrade", or "upgrade old store to version xxxx", etc?  Would be even more awesome for those that don't know how, or don't have the convenience of shell to toss things around.

 

Wil

Share this post


Link to post
Share on other sites
  • 0

Maybe I will turn it one day into a module. However, I don't think automation of the old store upgrade is desirable. The Prestashop upgrade process is notoriously brittle so I think that it is crucial that someone is actively looking at the messages that are emitted during the process.

Share this post


Link to post
Share on other sites
  • 0

I thought that I had read that it upgrades the old to the same version of the new already. If not then never mind. I'm done with my import and have some feedback for you.

 

Not all shared hosting packages come with access to INFILE and OUTFILE. Actually the secure ones don't.  Special permission needs to be given to access those files.  Secondly the ~mysql user shouldn't have access to the user folders so the $basepath isn't writable.  Being the host I was of course able to get around this but not everyone has my access.

 

GRANT FILE ON *.* TO 'imako_imakops'@'localhost';
GRANT FILE ON *.* TO 'stagingi_ps1'@'localhost';
flush privileges;
 
That gave the oldshop user and the newshop user access.  However, it still wasn't writable in the users' jailed folder.  I had to take $basepath out and change it to ./ so that the ~mysql user could write the files, which of course went into it's own ~mysql/ folder. Afterwards I just deleted them from there.
 
I think you could get around all of this if you wrote to temporary tables on the destination shop's database.  So instead of writing then reading from copy_shopdata_address.dtx just write and read from a copy_shopdata_address table. After completion drop table. I also think that would do better on benchmarks.
 
Wouldn't that work better or is there something about the dtx formatting that made it necessary?
 
Wil
 
--------------
14:26:14
oldconn = localhost.imako_imakops = 2532436
new conn = localhost.stagingi_ps1 = 2532435
2 old languages; 2 new languages. Language check ok.

Initialization skipped because it had already run
Copying tables

1 accessory 0
2 address 44355

MySQL error 1: Can't create/write to file '/home/xxxxxxx/public_html/exxxx5ckcmg82/prestools/copy_shopdata_address.dtx' (Errcode: 13 - Permission denied)
Generated by URL '/exxxx5ckcmg82/prestools/copy_shopdata.php'
with Query 'SELECT `id_address`,`id_country`,`id_state`,`id_customer`,`id_manufacturer`,`id_supplier`,`id_warehouse`,`alias`,`company`,`lastname`,`firstname`,`address1`,`address2`,`postcode`,`city`,`other`,`phone`,`phone_mobile`,`vat_number`,`dni`,`date_add`,`date_upd`,`active`,`deleted` INTO OUTFILE '/home/xxxxx/public_html/eyxxx5ckcmg82/prestools/copy_shopdata_address.dtx' FROM `ps_address`'

Edited by A-Z Hosting

Share this post


Link to post
Share on other sites
  • 0

Hi Wil,

 

Thank you for the feedback.

 

The recommended method is downloading to your localhost and upgrading there. This also fits with the pattern that people usually simultaneously take a new template and make other changes. As Prestashop's upgrade process is rather buggy and as there haven't been new features for quite some time upgrading for the sake of it is only recommended if there is a specific bug that bothers you and that is fixed in the new version. Copy-shopdata has been mainly developed with this localhost scenario in mind.

 

Copy-shopdata has been developed at a time when there was nothing. So many people for whom the automatic and manual upgrades failed felt they were stuck. That was the problem this software was meant to solve.

 

The problem with on-server upgrades is that there are so many scenarios. In many cases an upgrade involves a move to a new server. Some hosting providers allow remote access to the database. Others not [that's what the dtx files are meant to solve]. Writing rights to files are often a problem. Copy-shopdata could be much improved in this area. But I don't have the time and money. Neither do I have a clear vision on the best way to implement it.

 

So thank you for your feedback. Every bit helps to make the software better.

Share this post


Link to post
Share on other sites
  • 0

Can I move data from 1.6 to 1.7 with this tool?

I'm getting:

 

MySQL error 1054: Unknown column 'id_theme' in 'field list'
Generated by URL '/aaaa/admin3/pst/copy_shopdata.php'
with Query 'SELECT id_theme FROM ps_shop order by id_shop'

 

I checked 1.7 version and there is no id_theme but theme_name field in ps_shop.

Share this post


Link to post
Share on other sites
  • 0

Can I move data from 1.6 to 1.7 with this tool?

I'm getting:

 

MySQL error 1054: Unknown column 'id_theme' in 'field list'

Generated by URL '/aaaa/admin3/pst/copy_shopdata.php'

with Query 'SELECT id_theme FROM ps_shop order by id_shop'

 

I checked 1.7 version and there is no id_theme but theme_name field in ps_shop.

 

Thank you for reporting the problem. I will have a look into it. For the meantime I advise you to delete ps_Shop from the copied tables.

Share this post


Link to post
Share on other sites
  • 0

With version 0.24 I have made an update that also works with Prestashop 1.7.

 

It means that new 0.24 works between different versions 1.6 -> 1.7??

 

Or simply copy from 1.6 to 1.6 and 1.7 to 1.7?

 

Thanks, for info.

Edited by Rudolfo78

Share this post


Link to post
Share on other sites
  • 0

It means that new 0.24 works between different versions 1.6 -> 1.7??

 

Or simply copy from 1.6 to 1.6 and 1.7 to 1.7?

 

Thanks, for info.

In principle Copy_shopdata is for copying between the same version. The goal is to get rid of defects in the settings of the old shop.

 

However, very little has been changed in the business data between 1.6 and 1.7. So updating this way might work. But at your own risk: I haven't tested it.

Share this post


Link to post
Share on other sites
  • 0

In the new version I deleted the ps_meta and ps_meta_lang tables from the list of tables that were copied. It turned out that copying those could cause problems with translations of pretty urls. For example for order confirmation the Dutch files should look like the following

http://www.myshop.com/order-bevestiging?id_cart=6&id_module=3&id_order=6&key=f3d234d2476a951b5c80234rr44524804

But instead in one case it looked like

http://www.myshop.com/index.php?controller=order-confirmation?id_cart=124998&id_module=3&id_order=24049&key=c45te4f3t34d65292e44fd5c

If you have such problems you should copy the meta and meta-lang tables from a fresh installation of the PS version that you copied to. It may also be necessary to also install your new theme there first. 

Please note that:

 - this will be only a problem in some shops - not all

 - this will not harm the normal functioning of your shop. Until now the only place where I found it causing problems was in setting goals for Google analytics.

 

Edited by musicmaster

Share this post


Link to post
Share on other sites
  • 0

In version 0.26 a new function (and file) has been added: module-map. It gives a table that shows you which modules are present in the old and the new shops. That way you won't forget to install some modules.

The name of the file is copy_shopdata_modulemap.php. It will be run at the end of copy_shopdata.php and it can also be run independently.

Share this post


Link to post
Share on other sites
  • 0

FYI since I found your plug-in investigating an upgrade from 1.6.1.18 -> 1.7.3.0

Quote

26 cart_product 336401 structure different. Extra in new: id_customization,
MySQL error 1366: Incorrect integer value: '' for column 'id_customization' at row 1
Generated by URL '/adm/prestools_suite/copy_shopdata.php'
with Query 'LOAD DATA INFILE 'xxxxxxxxxxxxxxxxx/adm/prestools_suite/copy_shopdata_cart_product.dtx' INTO TABLE `ps_cart_product` CHARACTER SET 'utf8''

 

Example from the dtx file

20    22    0    1    0        1    2011-04-19 20:07:15
23    48    0    1    84        1    2011-04-26 10:48:17

Share this post


Link to post
Share on other sites
  • 0

Deleted the new column as a test and that gives duplicate data

 

MySQL error 1062: Duplicate entry '107115-1834-0-0' for key 'PRIMARY'

Share this post


Link to post
Share on other sites
  • 0
19 hours ago, morepix said:

Deleted the new column as a test and that gives duplicate data

 

MySQL error 1062: Duplicate entry '107115-1834-0-0' for key 'PRIMARY'

 

I have checked what has changed in the database structure in 1.7.3 and it is a bit too much. If you want to use Copy_Shopdata this way you should do it towards version 1.7.2.4 and then go to 1.7.3 with the 1-click upgrade.

Share this post


Link to post
Share on other sites
  • 0

Hello, and thank you for your work. 

I've managed to migrate the whole of my PS 1.6.1.16 to a new install of 1.7.3.1
It ran FLAWLESSLY. 

It ported over user accounts, user information, user orders, actual products that I can visit in the website (via direct category URL access). It came in with shipping methods and payment methods.
It came in with products, categories, category structure, pricing, tax info, stock levels, you name it. 

I can place an older with my old user from the old website.


However, I have a single problem still. Even though I can create an order and have it seen in the back office, when I go hit products in the left menu, to see my products in the backoffice, the list is empty. But like I said, the actual front office DOES see them, I can even use the ajax search, it's unbelievable how well this worked :)). 

 

If I go through an order in the backoffice and click on any product that has been order, I do get the product form working, it's just that I don't see products in the actual Products section (w perfect stock, and languages!)

Is there anything I can do so my products show up in the backoffice? Has this happened in your experience? I'm ready to start doing tests on the production server as well, but my team won't be able to do much if they don't see the products in the back office. 

Here is the output of the copyshop script on the product section: 

149 product 118 structure different. Extra in old: id_product_redirected, Extra in new: isbn, low_stock_threshold, low_stock_alert, additional_delivery_times, id_type_redirected, show_condition, state, 
150 product_attachment 0
151 product_attribute 133 structure different. Extra in new: isbn, low_stock_threshold, low_stock_alert, 
152 product_attribute_combination 168
153 product_attribute_image 85
154 product_attribute_shop 133 structure different. Extra in new: low_stock_threshold, low_stock_alert, 
155 product_carrier 0

I'll debug this further tomorrow, but I'm thinking that perhaps you might have encountered this before?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×