Restauration base de données

[GREG1]

Bonsoir Regis,

Pour conclure, je suis en ver 2.6.1, est ce raisonnable de migrer en 2.7 pour ensuite faire ma sauvegarde puis formater puis réinstaller dolibarr en 2.7 et enfin restaurer sans avoir toutes ces erreurs puisque d’après vous le pb semble être résolu en 2.7 ?
N’y a t il pas de risques a migrer de la 2.6.1 a la 2.7 sans être sur des sauvegardes ?

Merci pour vos précisions.

Greg

[GREG1]

Bonsoir Yves,

Mettre les droits pour ensuite les supprimer, est ce nécessaire ?
D’après vous les messages d’erreur n’ont pas d’incidence sur les données sauvegardées, alors pourquoi cette manipulation ?
J’ai de mon coté tenter quelques contrôles de cohérence suite a une sauv-restauration avec votre 1ere méthode et les qq erreurs. Globalement tout semble revenir a sa place, le nb de factures, le nb de clients, les factures reglées, en retard, le CA … enfin tt semble coller entre l’avant et l’apres sauv-restauration.

Merci encore pour tout.

Greg

[yves97]

GREG écrit:

Bonsoir,

Mettre les droits pour ensuite les supprimer, est ce nécessaire ?

C’est juste pour déranger le moins possible

D’après vous les messages d’erreur n’ont pas d’incidence sur les données sauvegardées, alors pourquoi cette manipulation ?

Pour le plaisir de faire disparaître les messages d’erreur.

Plus sérieusement, c’est précisément cette manipulation et ses effets qui me fait conclure que les messages d’erreur n’ont pas d’incidence sur les données.

Donc, la description de la manipulation est là pour permettre à quelqu’un qui ne serait pas d’accord avec ma déduction d’objecter.

[shelhatem]

bonjour,
Je posterai un guide graphique d’ici quelques jours sur la procedure de récuperation d’un systeme doliwamp.
J’espere pas plus tard que samedi soir ou dimanche matin.
Merci

[shelhatem]

bonsoir,
j’ai promis un guide avec des captures d’ecran.
Le voici en piece jointe.
j’attends vos feedback.
Merci

La pièce jointe doliwampp.zip est absente ou indisponible

[point]

os : mdv 2010
mysql : mysql Ver 14.14 Distrib 5.1.40, for mandriva-linux-gnu (x86_64)
dolibarr : 2.7.0

Bonjour,

j’ai un problème de restauration de donnée .
après un :

mysql dolibarr -h localhost -u root -p < mysqldump_dolibarr_2.7.0_201001011639.sql

j’obtiens un

ERROR 1005 (HY000) at line 25: Can’t create table ‹ dolibarr.llx_accountingaccount › (errno: 150)

de la ligne 22 à 43 j’ai :

DROP TABLE IF EXISTS llx_accountingaccount;
/*!40101 SET @saved_cs_client = @@character_set_client /;
/!40101 SET character_set_client = utf8 /;
CREATE TABLE llx_accountingaccount (
rowid int(11) NOT NULL AUTO_INCREMENT,
fk_pcg_version varchar(12) COLLATE utf8_unicode_ci NOT NULL,
pcg_type varchar(20) COLLATE utf8_unicode_ci NOT NULL,
pcg_subtype varchar(20) COLLATE utf8_unicode_ci NOT NULL,
label varchar(128) COLLATE utf8_unicode_ci NOT NULL,
account_number varchar(20) COLLATE utf8_unicode_ci NOT NULL,
account_parent varchar(20) COLLATE utf8_unicode_ci DEFAULT NULL,
PRIMARY KEY (rowid),
KEY idx_accountingaccount_fk_pcg_version (fk_pcg_version),
CONSTRAINT fk_accountingaccount_fk_pcg_version FOREIGN KEY (fk_pcg_version) REFERENCES llx_accountingsystem (pcg_version)
) ENGINE=InnoDB AUTO_INCREMENT=103 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
/!40101 SET character_set_client = @saved_cs_client */;

–
-- Dumping data for table llx_accountingaccount

LOCK TABLES llx_accountingaccount WRITE;

J’ai essayé avec les réponses précedentes sur les histoires de LOCK TABLES etc , mais j’ai rien compris .

question : comment faire pour restaurer ?

merci

[yves97]

point écrit:

Bonjour, et bonne année,

question : comment faire pour restaurer ?

En principe, il faut suivre le mode opératoire décrit ici:

Restaurations

Juste une remarque (qui n’a certainement rien à voir avec ton problème):
Normalement, il y a un utilisateur tartempion qui est
propriétaire de la base dolibarr, pas root. Cet utilisateur a été
défini, ou on lui a attribué la propriété de la base, lors de
l’installation initiale de dolibarr.

Donc la ligne de commande de restauration devrait plutôt être

mysql dolibarr -h localhost -u tartempion -p < mysqldump_dolibarr_2.7.0_201001011639.sql

J’ai essayé avec les réponses précedentes sur les histoires de LOCK TABLES etc , mais j’ai rien compris .

Il ne s’agit pas du même problème.

yves@intrepid-ibex:~$ perror 150
MySQL error code 150: Foreign key constraint is incorrectly formed

Là, ça me dépasse…

[point]

yves97 écrit:

Donc la ligne de commande de restauration devrait plutôt être

mysql dolibarr -h localhost -u tartempion -p < mysqldump_dolibarr_2.7.0_201001011639.sql

disons qu’avant j’ai toujours fait
mysql dolibarr -h localhost -u root -p < mysqldump_dolibarr_*********.sql

et ça fonctionnait bien (mais bon il y a bien 4 mois que je n’avais pas mis le nez dedans ) .

Je ne sais pas si c’est lié à la migration 2.6.1 -> 2.7.0 ?

grosso modo ,j’ai fait une migration 2.6.1-> 2.7.0 (sous mdv 2009) , j’ai sauvegardé avec les outils de dolibarr comme avant , installé la mdv 2010 , installé 2.7.0 , et là je bloque sur la restauration .

[yves97]

point écrit:

grosso modo ,j’ai fait une migration 2.6.1-> 2.7.0 (sous mdv 2009) , j’ai sauvegardé avec les outils de dolibarr comme avant , installé la mdv 2010 , installé 2.7.0 , et là je bloque sur la restauration .

Le problème n’est pas reproductible sur mon installation (dolibarr 2.7.0 sur ubuntu 8.10, venant aussi d’une migration 2.6.1-> 2.7.0).
Pour info, voici mes lignes 22 à 44

DROP TABLE IF EXISTS llx_accountingaccount;
SET @saved_cs_client = @@character_set_client;
SET character_set_client = utf8;
CREATE TABLE llx_accountingaccount (
rowid int(11) NOT NULL auto_increment,
fk_pcg_version varchar(12) NOT NULL,
pcg_type varchar(20) NOT NULL,
pcg_subtype varchar(20) NOT NULL,
label varchar(128) NOT NULL,
account_number varchar(20) NOT NULL,
account_parent varchar(20) default NULL,
PRIMARY KEY (rowid),
KEY idx_accountingaccount_fk_pcg_version (fk_pcg_version),
CONSTRAINT fk_accountingaccount_fk_pcg_version FOREIGN KEY (fk_pcg_version) REFERENCES llx_accountingsystem (pcg_version)
) ENGINE=InnoDB AUTO_INCREMENT=103 DEFAULT CHARSET=latin1;
SET character_set_client = @saved_cs_client;

–
-- Dumping data for table llx_accountingaccount

LOCK TABLES llx_accountingaccount WRITE;
/*!40000 ALTER TABLE llx_accountingaccount DISABLE KEYS */;

note que si je remplace mes lignes 22 à 44 par les tiennes, en tentant une restauration, j’ai:

ERROR 1005 (HY000) at line 25: Can’t create table ‹ ./dolibarr/llx_accountingaccount.frm › (errno: 150)

[point]

Bonsoir,

après plusieurs tests , voici ce que j’ai comme résultat

j’ai reinstallé mdv 2009.1 + lamp .

j'installe dolibarr 2.6.0 .  j'essaye un

 mysql dolibarr -h localhost  -u root -p < mysqldump_save_venant_de_dolibarr_2.6.1.sql     

fonctionne bien

j’essaye un

 mysql dolibarr -h localhost  -u root -p < mysqldump_save_venant_de_dolibarr_2.7.0.sql     

fonctionne bien

j’efface tout

j’installe dolibarr 2.7.1

j’essaye

 mysql dolibarr -h localhost  -u root -p < mysqldump_save_venant_de_dolibarr_2.6.1.sql     

fonctionne pas

j’ai le message : ERROR 1005 (HY000) at line 25: Can’t create table ‹ dolibarr.llx_accountingaccount › (errno: 150)

j’essaye

 mysql dolibarr -h localhost  -u root -p < mysqldump_save_venant_de_dolibarr_2.7.0.sql     

fonctionne pas

j’ai le message ERROR 1005 (HY000) at line 25: Can’t create table ‹ dolibarr.llx_accountingaccount › (errno: 150)

il me reste à refaire une migration 2.6.x -> 2.7.1 et à essayer des restaurations
après coup … la suite dans quelques minutes

[point]

après migration … je sauvegarde , ce qui donne un mysqldum_dolibarr_2.7.1_ect.sql

j’essaye ensuite un

  mysql dolibarr -h localhost -u root -p < mysqldum_dolibarr_2.7.1_ect.sql

et ça fonctionne

bon ne crions pas victoire … le but de l’opération est d’utiliser les sauvegardes issues de 2.7.1 pour une restauration sur un dolibarr 2.7.1 neuf de chez neuf sans passer par une migration .

la suite dans quelques minutes .

[point]

ayé le mot final

j’ai reinstallé dolibarr 2.7.1 neuf de chez neuf .

j’essaye de restaurer une sauvegarde issue d’un dolibarr 2.7.1 migré

et

..... suspens 

ça ne fonctionne pas !!

ERROR 1005 (HY000) at line 25: Can’t create table ‹ dolibarr.llx_accountingaccount › (errno: 150)

donc gros problème à l’horizon … car en l’état si je veux réutiliser les sauvegardes en cas de crash du matos , il faut que je reinstalle la 2.6.0 dans un premier temps , que je migre vers la 2.7.1 puis seulement j’utilise la sauvegarde . Dans 2 ans , si il faut toujours appliquer la même méthode , il faudra que j’installe la 2.6.0 ,que je migre vers la 2.7.x , puis que je migre vers 2.8.x ,puis que je migre vers 2.9.x puis que je migre vers 3.0.x et seulement à ce moment je pourrais utiliser mes sauvegardes . pas très pratique

[regis]

tu as fait la sauvegarde directement dans Dolibarr ?
si non il faut bien vérifier que la vérification des clés étrangères soit désactivées à l’import

[point]

regis écrit:

si non il faut bien vérifier que la vérification des clés étrangères soit désactivées à l’import

bonjour,

où dois je regarder pour désactiver avant import ?

[regis]

dans ton fichier de sauvegarde sql tu dois avoir ceci au début comme première requête :

SET FOREIGN_KEY_CHECKS=0;

et ceci à la fin du fichier comme dernière requête :

SET FOREIGN_KEY_CHECKS=1;

[point]

effectivement au début du fichier j’ai la ligne suivante

/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;

et en fin de fichier

/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;

[point]

Lors de la sauvegarde , au champ « Compatibilité du fichier export généré »

je mets d’habitude « NONE » (j’utilise mysqli pour le pilote - mysql Ver 14.14 Distrib 5.1.40 )

quelle option à ce champ vous donnez ?

Merci

[regis]

c’est bon,
par contre lorsque tu restaures est-ce que ta base est vide ou si il y a encore les tables est-ce que ton fichier sql de ta sauvegarde contient des DROP tables ?

[yves97]

point écrit:

effectivement au début du fichier j’ai la ligne suivante

/*!40014 SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;

et en fin de fichier

/*!40014 SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS */;

Les caractères /* et */ sont là pour commenter le code.

Du coup, les lignes ci-dessus n’ont aucun effet.

[point]

Effectivement .Je teste ce soir et je rends compte .
merci pour l’info