Jump to content

[résolu] Problème lors de MAJ 1.4.8 - 1.5.2

NOa
 Share

Recommended Posts

NOa Newbie

NOa

Posted
Posted (edited)

Bonjour,

 

voici mon problème :

Le 1-click install ne fonctionnant pas, j'ai suivit pas a pas l'upgrade manuel sur la documentation en respectant tout ce qui était indiqué. Mais je me retrouve avec les mêmes erreurs constamment ( voir le fichier texte en pièce jointe ou l’aperçu ci dessous.

 

Warning: PDO::query(): MySQL server has gone away in E:\Program Files (x86)\EasyPHP-12.1\www\classes\db\DbPDO.php on line 81
Warning: PDO::query(): Error reading result set's header in E:\Program Files (x86)\EasyPHP-12.1\www\classes\db\DbPDO.php on line 81
Warning: Invalid argument supplied for foreach() in E:\Program Files (x86)\EasyPHP-12.1\www\install\upgrade\php\generate_root_category_for_multishop.php on line 33

----------------fichier trop long voici les dernières lignes---------------------

Warning: Cannot modify header information - headers already sent by (output started at E:\Program Files (x86)\EasyPHP-12.1\www\install\upgrade\php\move_translations_module_file.php:26) in E:\Program Files (x86)\EasyPHP-12.1\www\install\upgrade\upgrade.php on line 425
[insert order detail 2] - MySQL server has gone away
[insert order 2] - MySQL server has gone away
unable to rename tables orders_2 and order_detail_2 to orders and order_detail]]> ALTER TABLE `ps_carrier` ADD `id_reference` int(10) unsigned NOT NULLMySQL server has gone away ALTER TABLE `ps_carrier` ADD `id_tax_rules_group` INT(10) unsigned DEFAULT "0" AFTER `id_reference`MySQL server has gone away ALTER TABLE `ps_cart` ADD `id_shop_group` int(11) unsigned NOT NULL DEFAULT "1"MySQL server has gone away ALTER TABLE `ps_cart_product` ADD `id_shop` `id_shop` int(10) unsigned NOT NULL DEFAULT "1" AFTER `id_address_delivery`MySQL server has gone away ALTER TABLE `ps_cart_product` ADD `id_product_attribute` int(10) unsigned DEFAULT NULL AFTER `id_shop`MySQL server has gone away]]>

 

De plus j'ai tenté de faire une install neuve de la 1.4.8 en important juste les bases ps_orders (+ toutes celles commencant par ps_order_) et les tables customers. Je retombe sur les memes erreurs en passant sur la 1.5.2.

J'ai alors tentee de faire une install neuve de la 1.4.8 sans importer quoi que ce soit et bien entendu çà marche parfaitement...

 

une idée ? Ma table ps_orders doit contenir au moins 700lignes

erreurs.txt

Edited by NOa (see edit history)
Link to comment
Share on other sites
NOa Newbie

NOa

Posted
  • Author
Posted

pas d’idée ? Je suppose que l'upgrade n'arrive pas à renommer la table orders_2 et order_detail_2 (généré lors de l'upgrade) via la fonction "mo_renameTables" dans le fichier "migrate_orders.php"... mais pourquoi ?

 

Existe-t-il un script qui pourrait transformer ma table ps_orders et ps_order_detail 1.4.8 en 1.5.2 pour que je puisse l'importer manuellement une fois la maj effectuée sur toutes les autres tables ?

Link to comment
Share on other sites
Muad'Dib Newbie

Muad'Dib

Posted
Posted

Bonjour NOa,

 

 

Toutes les modifications appliquées aux bases durant l'update sont dans /install/upgrade/sql où il faut prendre du numéro de votre version à suppérieur.

 

De plus vous pouvez trouver le détail exact des commandes Mysql qui ne sont pas passées dans le fichier généré au cours de l'installation dans le répertoire /log/.

 

 

En espérant que cela vous aidera.

 

 

A+

Link to comment
Share on other sites
NOa Newbie

NOa

Posted
  • Author
Posted (edited)

Voila ce que j'ai fait :

J'ai tenté de faire l'update de tout le site mais avec juste les 180 premières lignes de la table ps_orders et ps_order_detail (en me disant que ca sera moins lourd)(donc mes 180 premières commandes). Tout a parfaitement marché et dans le backend 1.5.2 mes commandes sont disponibles ... J'ai donc tenté de refaire l'update mais avec les 180 lignes suivantes et j'ai pas d'erreurs mais quand je check la base de donnée la table ps_orders et ps_order_detail ... vide...

 

De plus vous pouvez trouver le détail exact des commandes Mysql qui ne sont pas passées dans le fichier généré au cours de l'installation dans le répertoire /log/.

voici le début du fichier log si j update tout mon site de la 1.4.8 a 1.5.2

ERROR*  2012/12/08 - 17:20:27: PHP error: /* PHP:migrate_orders(); */
- 3 error(s) : <br/>[insert order detail 2] - MySQL server has gone away<br/>[insert order 2] - MySQL server has gone away<br/>unable to rename tables orders_2 and order_detail_2 to orders and order_detail
*ERROR*  2012/12/08 - 17:20:27: 1
*ERROR*  2012/12/08 - 17:20:27: SQL query:

 

edit : et je viens de tenter de faire la maj de tout le site sauf que je vide la table ps_order_detail vu que il me semble que ce soit elle qui fait buguer. résultat : la maj se fait mais la nouvelle table ps_order et ps_order_detail (normal pour celle-ci) est vide...

Edited by NOa (see edit history)
Link to comment
Share on other sites
Muad'Dib Newbie

Muad'Dib

Posted
Posted

Bizarre que vous ayez ce type d'erreurs.

 

Je n'ai pas perdu ou été obligé de supprimer mes tables orders quand j'ai fait mes MAJ sur mes sites, et à l'arrivée elles étaient toujours là.

 

En revanche pour ma part je ne suis pas passé en local mais fait les update directement sur des serveurs distants.

 

J'ai dans l'idée que EasyPHP n'est peut-être pas idéalement configuré par défaut pour l'exécution de script longs (je n'en ai aucune idée je présume). Parce que ce qui m'étonne quand même c'est que vous perdiez contact avec votre server MySQL local. Je me demande si le login/pwd MySQL a les droits suffisants pour effectuer toutes les opérations demandées sur les bases ou bien si certains points de syntaxe ne passeraient pas sous windows... jamais essayé.... je me permet juste de participer à votre brainstorming au cas où cela permettrai de trouver l'origine de votre problème.

 

 

En espérant que cela pourra vous être utile quand même.

 

 

A+

Link to comment
Share on other sites
Muad'Dib Newbie

Muad'Dib

Posted
Posted

J'ai également fait mes MAJ sur un mutualisé OVH sans soucis. Il m'est arrivé également de perdre la serveur SQL mais pas à chaque fois.

 

Par contre j'imagine que l'heure peut sans doute jouer là dedans.

 

En revanche après une tentative infructueuse, pensez bien à droper toutes les tables avant de resynchroniser votre BDD sauvegardée car la MAJ en crée des nouvelles sans les droper au préalable, ce qui pourrait sans aucun doute poser problème.

 

Pour info voici ce que j'ai gardé de la procédure manuelle, revue à ma sauce.

 

Assumant que tout est déjà bien sauvegardé

- j'ai désactivé tout ce qui n'était pas natif, module, thèmes, puis supprimé tous les répertoires en questions du serveur à mettre à jour.

- tar xvf prestashop-152.tgz sur le site à mettre à jour.

- install/upgrade/upgrade.php -> un certain nombre d'erreurs SQL sans intéret (je les ai vérifiée une par une dans mon cas).

- connexion au BO

- régénération des divers fichiers puis reparamétrage.

 

 

En espérant que cela vous aidera.

 

 

A+

Link to comment
Share on other sites
NOa Newbie

NOa

Posted
  • Author
Posted

A chaque tentative (phase de test de l'update) je vide tout, je fais une fresh-install de la version 1.4.8 (sans module custom et theme custom) et j'importe juste les tables ps_orders / ps_order_detail / ps_order_history / ps_customer...

Car j'ai déjà tenté de faire la maj avec toutes les tables sauf ces précédentes et tout se passe parfaitement. (et si je fait l'update avec toutes les tables de mon site en production je tombe sur les erreurs de mon premier post)

 

Ensuite je lance donc l'update. Parce que je compte refaire tout a 0 pour la 1.5.2 (themes modules) tout en gardant les bases importantes comme les commandes, clients, adresses...

 

A noter que ma table ps_order_detail fait 3557 lignes.

Link to comment
Share on other sites
Muad'Dib Newbie

Muad'Dib

Posted
Posted

Ma table ps_orders doit contenir au moins 700 lignes.

A noter que ma table ps_order_detail fait 3557 lignes.

 

Du coup cela explique mieux pourquoi le serveur MySQL tombe dans les choux du coup... <_<

 

Vous avez un serveur dédié ou un mutu?

Utilisez vous une des bases gratuite venant avec l'installation des modules ou votre base common?

 

Dans votre cas effectivement il faudra peut être effectuer les motifs des bases en local pour ne pas faire planter MySQL.

 

Mais là j'avoue que je vais sans doute avoir du mal à vous aider si c'est bien la taille de vos bases qui pose problème.

 

Avez vous essayer de mettre à jour la base (vide) puis de réimporter les tables en question (après avoir ajusté en local les éventuels champs qui auraient été changés au passage) dans la BDD déjà modifiée?

 

 

Bonne chance!

 

 

A+

Link to comment
Share on other sites
NOa Newbie

NOa

Posted
  • Author
Posted
Vous avez un serveur dédié ou un mutu?

mon OVH est mutualisé et ovh ne veut pas modifier la limit memory de mysql.

 

Utilisez vous une des bases gratuite venant avec l'installation des modules ou votre base common?

je ne comprend pas la question :x

 

Avez vous essayer de mettre à jour la base (vide) puis de réimporter les tables en question (après avoir ajusté en local les éventuels champs qui auraient été changés au passage) dans la BDD déjà modifiée?

J'essaye depuis des semaines. Il me faudrait donc juste un script pour modifier mes 2 tables ps_orders et ps_order_detail en local (je le ferait manuellement par pack de 180 lignes), vu que tout le reste ne pose pas de probleme lors de la maj.

Link to comment
Share on other sites
Muad'Dib Newbie

Muad'Dib

Posted
Posted

mon OVH est mutualisé et ovh ne veut pas modifier la limit memory de mysql.

 

Oui ça c'est normal si vous voulez changer cette valeur il faut passer en dédié <_<

Par contre en local vous devriez pouvoir changer cette valeur non?

 

 

je ne comprend pas la question :x

 

En fait lorsque vous installez un module depuis votre hébergement cela vous créer par défaut une base 'defaut' gratuite qui est limitée (normale puisque gratuite). En revanche dès que vous avez un compte pro ou supérieur je crois, votre hébergement comprend une autre base pour y installer les modules avec pour nom ****common. Cette base de plus grande capacité a aussi des paramètres de connections différents. L'utiliser résolverait peut-être (sans garantie) votre problème.

 

 

Bon courage!

 

 

A+

Link to comment
Share on other sites
NOa Newbie

NOa

Posted
  • Author
Posted

En local j'avais mis les limites bien larges je vais tenter de mettre encore plus large.

 

Concernant mon OVH c'est l'offre "pro" qui contient une base "SQL PRO" de grande capacite (celle utilisee par le site)

Link to comment
Share on other sites
NOa Newbie

NOa

Posted
  • Author
Posted (edited)

Bon, je souhaite te remercier Muad'Dib.

 

Tout marche après avoir augmenté encore plus le max_allowed_packet de mysql.

Difficile de faire transpirer les émotions sur un forum, mais franchement je suis ultra-content.

Ta simple implication à mon problème m'a redonné la motivation de continuer sur la résolution de mes soucis avec prestashop.

 

Encore un grand merci à toi encore une fois.

 

(et merci aux admins de presta de leur aide?)

Edited by NOa (see edit history)
Link to comment
Share on other sites
Muad'Dib Newbie

Muad'Dib

Posted
Posted

Pas de quoi, cela me fait très plaisir d'avoir pu participer à te remotiver à défaut d'avoir pu te donner la solution immédiatement :)

 

De mon coté j'ai mis 1 semaine avant de maîtriser ma propre migration de 1.2.5 à 1.5.2, juste pour identifier à 100% les éléments qui posaient problème et distinguer ce qui résultait d'un problème de migration, simplement d'interprétation ou bugs de la nouvelle version. Il suffit parfois de si peu de choses pour finalement <_<

 

A mon avis le changement est moins important de la 1.4.8 à la 1.5.2 (ne serait-ce que pour le theme par défaut) mais je dois avouer que pour ma part le changement est vraiment très important alors "try & fail" rules :P

 

Quand on a un backup, où est le problème hein? :D

 

 

A bientôt!

Link to comment
Share on other sites
  • 2 weeks later...
  • 5 months later...
  • 8 months later...
Johann Contributor

Johann

Posted
Posted

Première fois que j'ai ce problème en quelques dizaines de mises à jour diverses et variées.

Je viens donc d'avoir le pb lors d'un passage 1.4.7.3 -> 1.5.6.2, pourtant sur un gros serveur dédié.
La solution a fonctionné pour moi aussi, merci beaucoup :)

Link to comment
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
 Share
Go to topic listing
×
×
  • Create New...