Quel chemin de mise à jour depuis v.3.3.1?

Bonjour à tous,
Ma fille utilise Dolibarr v. 3.3.1 installé en 2013 pour sa facturation. Elle est maintenant sous Windows 10.
Sur conseil d’une amie elle vient d’acheter et d’installer Avast.
Elle n’a plus accès à Dolibarr installé en local sur son PC.
Je suppose que c’est le serveur Apache qui est bloqué, mais je pense que c’est peut être le moment de mettre à jour Dolibarr.
Elle a essayé la dernière version de DoliWamp qui ne peut pas gérer MySQL 5.0.45.
Existe-t-il un chemin recommandé par étapes pour faire une mise à jour ?
Aussi, elle ne peut pas faire une sauvegarde donc peut-on juste copier le dossier C:\dolibarr avant de commencer ?
Merci pour votre aide.
Chris

Bonjour @cerdal

Prenons les choses dans l’ordre :

oui surement : donc paramétrer correctement avast ou le désinstaller, le temps de retrouver un accès à dolibarr et faire au moins une sauvegarde (et stocker cette sauvegarde ailleurs que sur ce même PC)

aie aie aie : sur le même PC ? ça a pu écraser tout ou partie de ce qui existait avant (dépendant de ce qu’elle a fait) mais pour la suite: mettons que rien n’a été perdu.

non
(enfin si… mais vraiment très compliqué)

oui, le sujet a été abordé plusieurs fois sur le forum.
En gros : il faut considérer que la « mise à jour » ne se fait pas avec l’installateur doliwamp, mais est considérer comme une vrai migration:

  1. sauvegarde de la bdd et des documents (dans ton cas en 3.3.1)
  2. suppression propre de l’ancien environnement (le 3.3.1)
  3. création du nouvel environnement (par exemple installer doliwamp en V13.0.2)
  4. suppression en bdd de toutes les tables du nouvel environnement
  5. restauration de la sauvegarde en bdd et des documents (en fonction de ce que contient la sauvegarde, il faudra peut être la modifer légèrement à la main, vu qu’il ne faut recréer que les tables, et pas la bdd)
  6. se connecter à dolibarr, qui du coup va s’appercevoir que ses programmes sont en V13 alors que la bdd est en 3.3.1
    et donc se lancer dans V3 → V4 , V4->V5, etc… jusqu’en V13

Déjà, si tu fais ça, les données sont là et rien n’est perdu, bravo :slight_smile:

Ensuite … tu imagines bien que la V13 est très différentes de la V3…
donc il y aura du paramétrage à faire.

Merci Arre pour votre réponse détaillée.
Elle a désactivé Avast mais toujours le même message.
Elle a désinstallé Avast, mais toujours impossible de connecter à Dolibarr.
J’ai utilisé TeamViewer pour zipper et récupérer son dossier c:\Dolibarr sur mon PC W10 64bit.
J’ai téléchargé Doliwamp 3.3.1 (la version qu’elle utilisait) et je vais essayer de réinstaller Doliwamp sur ma copie de son dossier Dolibarr.
Pour l’instant je suis bloqué parce que je ne connais pas les logins pour MySQL et la base de données, et elle ne s’en souvient pas…
Je vais surement revenir ici dans quelques temps !
Chris

Finalement on n’a pas besoin des logins pour réinstaller 3.3.1.
J’ai pu faire un dump, copier le dossier documents sur un NAS, et j’ai relancé version 13.0.2.
Message d’erreur à cause de MySQL trop ancien upgrade error donc j’ai pris DoliWamp 5.0.0 et les mises-à-jour se passent bien.
Merci pour votre soutien moral qui m’a donné le courage de commencer le processus !
Chris

Tant mieux,

mais ne fais pas de mises à jour sans accéder au dolibarr, vérifier que tout est ok et sauvegarder (tu auras ainsi une install « propre » et une sauvegarde).

Après … tu peux faires autant de màj que tu veux et/ou restaurer ça chez ta fille et… tapes lui sur les doigts : sauvegarde externe au moins une fois par semaine (documents + bdd) + noter ses mots de pass + pas écouter de copine qui disent que c’est tropppppp biennnn d’installerrr çaaaaa sans en maitriser les conséquences :wink:

OK. Je suis arrivé à Doliwamp 11.0.0 sans problème, avec sauvegardes à v5, v8, v10 et v11.
J’ai installé à neuf Doliwamp v13.0.2 et j’essai de restaurer la base.
à chaque lancement dans une fenêtre cmd j’ai une erreur :
------------------------------------------8<-------------------------------------
C:\Dolibarr 11\dolibarr_documents\admin\backup>c:/dolibarr/bin/mariadb/mariadb10.4.10/bin/mysql dolibarr -h localhost -P 3306 -u dolibarrmysql -pchangeme < mysqldump_dolibarr_11.0.0_202103281616.sql
ERROR 1005 (HY000) at line 28: Can’t create table dolibarr.llx_accounting_account (errno: 150 « Foreign key constraint is incorrectly formed »)

C:\Dolibarr 11\dolibarr_documents\admin\backup>
------------------------------------------8<-------------------------------------

…et voici le script SQL. La ligne N° 28 est celle qui contient CREATE TABLE …
( N.B. J’ai rajouté 4 lignes DROP TABLE sur un conseil dans un autre fil que j’ai trouvé sur ce problème )
------------------------------------------8<-------------------------------------

– MySQL dump 10.11

– Host: localhost Database: dolibarr


– Server version 5.0.45-community-nt

/*!40101 SET @[email protected]@CHARACTER_SET_CLIENT /;
/
!40101 SET @[email protected]@CHARACTER_SET_RESULTS /;
/
!40101 SET @[email protected]@COLLATION_CONNECTION /;
/
!40101 SET NAMES utf8 /;
/
!40103 SET @[email protected]@TIME_ZONE /;
/
!40103 SET TIME_ZONE=’+00:00’ /;
/
!40014 SET @[email protected]@UNIQUE_CHECKS, UNIQUE_CHECKS=0 /;
/
!40014 SET @[email protected]@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 /;
/
!40101 SET @[email protected]@SQL_MODE, SQL_MODE=‹ NO_AUTO_VALUE_ON_ZERO › /;
/
!40111 SET @[email protected]@SQL_NOTES, SQL_NOTES=0 */;


– Table structure for table llx_accounting_account

DROP TABLE IF EXISTS llx_accounting_account;
DROP TABLE IF EXISTS llx_accounting_system;
DROP TABLE IF EXISTS llx_accountingaccount;
DROP TABLE IF EXISTS llx_accountingsystem;

DROP TABLE IF EXISTS llx_accounting_account;
CREATE TABLE llx_accounting_account (
rowid bigint(20) NOT NULL auto_increment,
entity int(11) NOT NULL default ‹ 1 ›,
datec datetime default NULL,
tms timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,
fk_pcg_version varchar(32) NOT NULL,
pcg_type varchar(20) NOT NULL,
pcg_subtype varchar(20) NOT NULL,
account_number varchar(32) NOT NULL,
account_parent int(11) default ‹ 0 ›,
label varchar(255) default NULL,
fk_accounting_category int(11) default ‹ 0 ›,
fk_user_author int(11) default NULL,
fk_user_modif int(11) default NULL,
active tinyint(4) NOT NULL default ‹ 1 ›,
import_key varchar(14) default NULL,
extraparams varchar(255) default NULL,
PRIMARY KEY (rowid),
UNIQUE KEY uk_accounting_account (account_number,entity,fk_pcg_version),
KEY idx_accountingaccount_fk_pcg_version (fk_pcg_version),
KEY idx_accounting_account_account_number (account_number),
KEY idx_accounting_account_account_parent (account_parent),
CONSTRAINT fk_accounting_account_fk_pcg_version FOREIGN KEY (fk_pcg_version) REFERENCES llx_accounting_system (pcg_version)
) ENGINE=InnoDB AUTO_INCREMENT=4785 DEFAULT CHARSET=utf8;
------------------------------------------8<-------------------------------------

Je ne sais plus quoi essayer.

Toute suggestion serait la bienvenue !

Bonjour @cerdal

Voir le Wiki

Pour moi ton

FOREIGN_KEY_CHECKS=0 /;

devrait être remplacé par

SET FOREIGN_KEY_CHECKS=0;

et tu n’as pas

SET SQL_MODE=« NO_AUTO_VALUE_ON_ZERO »;

Ne pas oublier d’insérer à la fin

SET FOREIGN_KEY_CHECKS=1;

Cordialement
Eric

Merci Eric.
J’avais déjà essayé ça sans succès, puis j’ai cherché à comprendre les lignes apparemment commentées en tète et en fin de fichier sql :

/*!40014 SET @[email protected]@UNIQUE_CHECKS, UNIQUE_CHECKS=0 /;
/
!40014 SET @[email protected]@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 /;
/
!40101 SET @[email protected]@SQL_MODE, SQL_MODE=‹ NO_AUTO_VALUE_ON_ZERO › */;

etc.
Il s’avère que cela indique une exécution conditionnelle, seulement si la version est >= 4.0.14 donc elles sont toutes exécutées.

J’ai enfin supprimé les lignes DROP TABLE que j’avais ajoutées et regardé le problème avec la fraicheur d’une belle matinée ensoleillée, et je me suis dit que je créais une table qui dépendait d’une autre qui n’existait pas encore.

J’ai déplacé la création de llx_accounting_system avant la creation de llx_accounting_account et tout s’est bien passé !

Merci à tous les deux pour votre aide.
Chris