Bienvenue sur la page communauté Sooth ERP, où vous pouvez poser vos questions. Inscrivez-vous (via le login de Mantis)

problème de mise à jour lmb avant passage vers sooth

0 votes
Bonjour, Et merci pour ce fork. Je voudrais migrer vers sooth, mais je remarque que je suis en version 2.052.0 de lmb et dois donc mettre à jour avant de commencer. J'ai trouvé sur leur ftp les dossiers nécéssaires, mais quoi que je fasse, installation automatique ou manuelle, la maj reste bloquée dès le début avec une ligne affichée au niveau de la maj: "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> Cela fait 2 jours que je tourne autour du problème et je n'entrevois pas de solution... Merci d'avance, -- Thierry Maes
posté Fev 16, 2014 dans la catégorie Problèmes par tmaes (200 points)

2 Réponses

0 votes
Bonjour,

à vrai dire je n'ai pas utilisé le canal de mise à jour LMB depuis un moment, mais effectivement, lorsque je l'ai fait dans le passé, c'était sous Win et cela n'a pas forcément toujours été facile, le système "d'auto update" me paraissait trop dépendant de l'environnement.

Bref, visiblement il doit y avoir un problème soit au niveau des fichiers d'origine de mise à jour, soit dans leur interprétation car pour que ce message soit affiché, c'est que des balises sont manquantes ou mal interprétées.

Dans quel environnement êtes vous ?

Cdt

Yves
répondu Fev 16, 2014 par Yves (3,790 points)
0 votes
Edit: je pense avoir trouvé (en affichant le debug depuis le fichier de config serveur) Easy php ne permettait plus le call-time ... j'ai donc du le permettre dans php.ini et ça a l'air de passer! allow_call_time_pass_reference = On Merci encore pour la réactivité --fin edit Merci pour ces réponses rapides, Je suis pour l'instant sous windows avec Easy php et je voudrais migrer vers mon serveur Linux. L'état actuel de mes tests: j'ai installé pour tests une version 'fraiche' de lmb sur mon easyphp , du coup j'ai une 2.061 correcte, j'ai réussi la maj jusqu'à la 2.071 sans souci avec cette version, la première ligne de rapport étant celle que je cite dans mon premier message, ensuite la maj continue sans problème... Si je fais la même chose avec ma version de travail, la maj reste bloquée à la première étape... Comme j'ai ma compta depuis 10 ans encodée, si je ne parviens pas à passer au-dessus de ce problème, je vais être bon pour importer table par table le contenu de ma compta ... ça va être lourd. Merci encore Cordialement, -- Thierry Maes
répondu Fev 16, 2014 par tmaes (200 points)
modifié Fev 16, 2014 par tmaes

Salut,

Le plus simple serait déjà de faire une copie de la base de donnée,

Ensuite passer (dans cette copie) les script de mise à jour (BDD) attention certaines actions MySQL sont présentes dans les fichiers php servant à faire le mise à jour.

Une fois que les mise à jour sont passées, il est tout a fait possible de plugger cette BDD avec des fichiers nouvellement installés (ça évite de devoir débugger de vieux fichiers pour qu’ils tournent avec une version php plus recente) Mais attention à bien faire ça sur une copie de mysql, les risque de crash et/ou echec de ce mode de mise à jour ne sont pas négligeable au vu de l’age de votre application !…

N’hésitez pas à nous tenir au courant.

Essayez de compiler tous les MySQL en un seul avant de lancer le script : un seul script à lancer sur un clone sera plus simple à utiliser, en cas de crash, il sera facile de le débugger pour le relancer du début sur un clone neuf, plutôt que de chercher à relancer tous les fichiers les uns après les autres !…

Et en plus, ça pourra être utiles à d’autres (si vous notez bien les versions en commentaire avant de coller le script suivant)

Si vous avez des difficultés pour créer ce script de mise à jour, on pourra essayer de vous donner un coup de main ;)

@Bientôt, et Bon courage (ce n’est pas simple de faire ce genre d’opération, et ce serait merveilleux d’y arriver du premier coup ^^)

Si vous n’arrivez pas à comprendre comment fonctionne le système de mise à jour, dites le, on vous guidera !

en attendant, BonWE !

Bonjour,

Et merci pour ces suggestions que je vais suivre, je vais faire un fichier contenant l'ensemble des requests mysql contenues dans les différentes maj, je les mettrai ici comme cela ça pourra éventuellement servir à d'autres...

--
Thierry Maes
Bonjour,

j'espère que vous avez réussi à avancer dans la migration.
La version de LMB dispo sur leur ftp est >= 2.060

Je suis à la recherche d'une version antérieure pour essayer d'établir un process pré-migration un peu plus stable.

Si vous en avez une, je suis intéressé. Merci :)

Yves
Je ne l'ai pas encore fait, je suis débordé pour l'instant; j'attaque cela dès que possible...

Pas de problème pour les fichiers, j'ai sous le coude une version de 2009 et 2013 (plus ou moins, je n'ai pas tjs été pile à jour...). Je peux vous les envoyer par mail ou autre. J'ai enlevé les dbs qui contiennent ma compta, s'il les faut aussi, il faudrait que je les vide d'abord...

--
Thierry Maes
Merci pour la réponse,

un autre membre vient de m'envoyer hier des version antérieures à 2.060, inutile donc de me renvoyer les vôtres (merci et désolé pour les manips engendrées du coup).

J'ai réussi à partir de là a faire une installation puis mise à jour depuis la version 2.038 jusqu'à 2.071 sous Windows.
Cela demande ceci dit quelques adaptations puisque qu'il y a des conflits qui viennent des versions Php d'une part et de l'api client Mysql des versions antérieures de Php (nécessaires pour que l'install passe) qui semblent incompatibles avec des versions plus récentes de Mysql (en tout cas dans mon environnement Uwamp)

Il est vrai qu'on repart de loin, donc les versions d'environnement ont évoluées, ce qui engendre des conflits.

Uwamp permettant relativement facilement de modifier les versions de serveurs sans s’immiscer au niveau de windows (ce qui évite des conflits supplémentaire en cas de multiples versions), j'ai réussi sous cet environnement à recréer des conditions qui permettent la mise à jour 2.038 jusqu'à 2.071.0.

Je vais créer une page avec les étapes à reproduire.

Cordialement,

Yves
Après différents essais, je suis repassé sur Uniform Server dont j'ai découvert les récentes et intéressantes évolutions.
Sous Uwamp, ça passait mais le proccess devenait *un peu* usine à gaz.
Uniform Server permet maintenant de switcher les versions de Php (et bien plus) et la mise à jour passe sans avoir à toucher à la version de Mysql (ce qui n'était pas le cas avec Uwamp).

En résumé donc et pour donner une solution immédiate: en s’équipant de la dernière version de Uniform Server (http://sourceforge.net/projects/miniserver/files/Uniform%20Server%20ZeroXI/) et en rajoutant les modules Php 5.2 et 5.3 on peut faire la mise à jour:
- Php 5.2 pour la mise à jour, puis
- Php 5.3 pour l'utilisation

Je créerai une page plus complète sur le wiki quand je trouverai un petit moment.
Bonjour,

Je viens de repasser deux jours sur cette (maudite) mise à jour, et je n'arrive à rien de probant. Vu mes connaissances très légères en php/mysql, je pense que je n'arriverai pas à compiler les différentes commandes mysql des mises à jour, certaines contenant des variable php...
c'est rageant pour les statistiques perdues (et les factures ,devis, articles, prix etc), mais je pense devoir reprendre depuis une version fraîche de sootherp et recommencer de 0.
Je vous remercie en tout cas pour les suggestions ci-dessus.
Re-bonjour,

en désespoir de cause, je suis passé en mode 'sauvage' et j'ai obtenu quelques résultats...
J'ai pris chaque maj.php, j'ai mis toutes les lignes en remarques, sauf celles concernant les dbs (donc jusqu'à $query_maj_sql = array();  )
J'ai mis en dur les coordonnées de db et user pw (je sais c'est mal).
Et pour chaque fichier je l'ai appelé depuis firefox, résultat, à chaque fois une page blanche mais je voyais dans les dbs que ça travaillait.
Arrivé à la 2.071, j'ai injecté le résultat dans sooth... et ça fonctionne à 75% . Je sais presque tout faire mais quand je recherche mes factures, il revient sur le bureau systématiquement.

N'y a-t-il pas un mode pour voir l'erreur? ou un log?
merci d'avance!
Hourra!
J'ai trouvé...
C'étaient 3 lignes dans la maj 2.060 qui posaient problème:
$query_maj_sql[] = "
ALTER TABLE `doc_fac` DROP FOREIGN KEY `doc_fac_ibfk_2` ;
";
en les commentant, on peut updater de la 2.52 à la 2.71 et il n'y a plus de problème (à première vue) à exploiter la db de lmb dans sooth.
J'ai sué 3 jours dessus, mais j'ai enfin un logiciel opensource pour ma compta qui pourra tourner sur mon serveur linux (avec mes 10 ans d'encodages précédents ). J'espère que sooth continuera et que je pourrai contribuer à son évolution...
Bonjour,

cela fonctionne-t-il toujours?
Commenter ce type de ligne me fait un peu peur.

Je vais tâcher de faire sous peu  un tuto vidéo sur la mise à jour depuis LMB (avec une version ancienne), vers Sooth ERP.
En espérant que cela pourra aider...

Cordialement,

Yves
Bonjour,

Oui cela fonctionne toujours, j'ai même émis ma première nouvelle facture aujourd'hui. Vous me faites un peu peur avec votre remarque...
Je dois en plus avouer qu'en exportant la db mise à jour vers la db en production, j'ai encore eu un message du même type entre les 2 phpmyadmin mais pour une autre table je cite:
SQL query:

--
-- Contraintes pour la table 'msg_types'
--
ALTER TABLE 'msg_types' ADD CONSTRAINT 'msg_types_ibfk_1' FOREIGN KEY ('id_msg_type_groupe') REFERENCES 'msg_type_groupe' ('id_msg_type_groupe') ON DELETE NO ACTION ON UPDATE CASCADE;

# 1452 - Cannot blabla (j'avais fait un printscreen...)

ET pour être complet, je dirais que ça fonctionne super bien, je n'ai pas encore eu le moindre bug ou alerte... vous pensez qu'il y a un risque de planter des tables ou des correspondances?
Pour le premier, c'était un drop key, la key n'existait pas, et il ne savait donc pas la jeter, je ne pense pas que ça pose problème... pour le dernier j'avoue que je suis passé au dessus sans me formaliser...

Merci pour la réponse!

Cordialement,

--
tmaes
...