11.0.4 et restauration de Base de données

Bonjour a vous.

J’ai une version en 11.0.4 hébergé chez OVH et tout se passe pour le mieux.
Je voulais tester des fonctionnalités supplémentaires et comme je veux pas les tester sur ma base de prod mais que j’y ait pas mal de données je me suis dit : « Tiens si tu faisait un copie de Ton dolibarr de prod sur une base de test, tu bidouille et après tu active sur la prod… »

Je vais sur mon serveur dédier OVH je créer mon petit espace « test » (il existe déja avec d’autres verison de Dolibarr et d’autres applis), je lui crée sa toute nouvelle base de donnée (testdoli11), je copie le répertoire documents, je dézip la svg automatique de cette nuit, je lance mon ssh, je vais dans mon répertoire test/doli1/documents/admin/backup
je lance ma ligne de commande

/usr/bin/mysql test -h mabasededonnees -P 3306 -u test -pLeMotDePasseDeLaMortQuiTue < monfichiersauvegarde.sql

Et la erreur,
ERROR 1022 (23000) at line 28: Can’t write; duplicate key in table ‹ prod_account ing_account ›

Je l’avais jamais eu celle ci. je check le wiki j’ajoute
SET FOREIGN_KEY_CHECKS=0;
SET SQL_MODE=« NO_AUTO_VALUE_ON_ZERO »;

je relance, idem.
J’utilise Phpmyadmin idem, je vais pour supprimer les table account… rien (pas de tables),

Des idées ? ca ne m’était jamais arrivé
J’ai essayer une restauration d’un 10.0.3 sans soucis

Bonjour
Juste avant la restauration de la base, videz la base de données en place en supprimant toutes les tables.
Attention à ne pas mélanger le nom des index et celui des tables.
Ne serait-ce pas le préfixe des tables qui est à « prod » ?
@+

Deux choses alors cela veut’il dire que si j’ai une base de données avec des tables existante je ne peut pas restaurer mes tables avec préfixe ?
et que la fonction « if exist drop table » n’est pas prise en compte par phpmyadmin en export/import (au dela de la sauvegarde de Dolibarr).

Apres normalement peut importe le préfixe il suffit normalement que aucune table ne corresponde (on peut tres bien installer autant de dollibarr que l’on veut sur une seule base de données normalement.)

Merci pour l’info je vais tester avec une base vide

J’ai fait une petite expérience sur avec phpmyadmin

j’ai exporté mes données

comme cela

– phpMyAdmin SQL Dump
– version 4.9.1
https://www.phpmyadmin.net/

– Hôte :
– Généré le : mar. 02 juin 2020 à 14:05
– Version du serveur : 5.6.47-log
– Version de PHP : 7.3.17

SET FOREIGN_KEY_CHECKS=0;
SET SQL_MODE = « NO_AUTO_VALUE_ON_ZERO »;
SET AUTOCOMMIT = 0;
START TRANSACTION;
SET time_zone = « +00:00 »;
USE test;



– Structure de la table prod_accounting_account

DROP TABLE IF EXISTS prod_accounting_account;
CREATE TABLE IF NOT EXISTS prod_accounting_account (
rowid bigint(20) NOT NULL AUTO_INCREMENT,
entity int(11) NOT NULL DEFAULT ‹ 1 ›,
datec datetime DEFAULT NULL,
tms timestamp NULL DEFAULT NULL,
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) NOT 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_accounting_account_fk_pcg_version (fk_pcg_version),
KEY idx_accounting_account_account_parent (account_parent)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

Et voila le résultat


> 

--
-- Contraintes pour les tables déchargées
--

--
-- Contraintes pour la table `prod_accounting_account`
--
ALTER TABLE `prod_accounting_account`
  ADD CONSTRAINT `fk_accounting_account_fk_pcg_version` FOREIGN KEY (`fk_pcg_version`) REFERENCES `prod_accounting_system` (`pcg_version`)

MySQL a répondu :
#1823 - Failed to add the foreign key constraint 'test/fk_accounting_account_fk_pcg_version' to system tables

Chelou

Certains index/contraintes sont nommés. Un même index avec le même nom ne peut toucher des tables différentes.
@+

Merci pour l’info. c’est bon a savoir. pour les index.
Mais çà résous pas mon soucis.

Se sont les ALTER TABLES en fin d’export qui posent problèmes.
Je vais me pencher la dessus

Il y a un autre Dolibarr dans la même base MySQL avec un autre préfixe ?