Carnet Wiki

Passage de SQLite à MySQL (et réciproque)

Version 16 — Juin 2022 Suske

Cet article date de 2013 n’est pas à jour  ! exec=article&id_article=4354&repondre=new ]. En ce beau mois de juin 2022 , Cette page explique la meilleure méthode recommandée et celle qui est la plus récente de passage de SQLite à MySQL en l’état de toutes  : utiliser la commande SPIP-Cli codée par Cédric exprès pour ça et disponible sur
[->
https://git SPIP 3 .spip.net/spip-contrib-outils/spip-cli/src/branch/master/src/Command/SqlConvertTomysql 7 - Merci de na pas la modifier sans discussion préalable [sur son forum privé->http://contrib .php] . net/ecrire/ ?

Tout le reste est déprécié.

MAJ 29/06/2022

Passage de MySQL à SQLite

Si vous avez un site test sous MySQL il suffit de faire une sauvegarde depuis le site et de la réimporter dans un site installé avec SQLite. Le passage dans ce sens est généralement très bien supporté et ne pose pas de problèmes.

Cette page expliquait une méthode

Passage de passage de SQLite à MySQL en l’état de SPIP 3 . MySQL

0.7

Elle a été discutée sur son forum privé et est donc officiellement obsolète Il existe aussi une procédure manuelle , plus complexe .

Son historique La soution la plus simple est disponible dans l’espace privé d’utiliser le plugin Fusion de Spip : [->https://contrib
http://contrib .spip.net/ecrire / ? net/Fusion-de-SPIP#sqlite exec=revision&id_objet=4354&objet=article]

Procédure manuelle pour passer sa base de SQLite à MySQL :

  • Sur le site 1 installé avec SQLite faire une sauvegarde dans tmp/dump/dump1.sqlite
  • Installer un site 2 avec MySQL avec tous les mêmes plugins (mêmes tables dans la base de données)
  • Sur ce site 2 (installé avec MySQL) faire une sauvegarde dans tmp/dump/dump2.sqlite
  • Exporter la table spip_meta du dump2.sqlite dans un fichier :
    echo ".dump spip_meta" | sqlite3 dump2.sqlite > metadump2.txt
  • Supprimer la meta de structure dans dump1.sqlite :
    echo "delete from spip_meta where nom='dump_structure_temp';" | sqlite3 dump1.sqlite
  • Mettre à jour la table spip_meta dans dump1.sqlite :
    sqlite3 dump1.sqlite < metadump2.txt
  • Importer le dump1.sqlite dans le site 2 sous MySQL depuis l’interface SPIP.

Cette procédure repose sur le fait que les bases du site 1 et du site 2 ont les mêmes tables avec les mêmes champs. Il faut donc faire bien attention à avoir tous les mêmes plugins installés.

Procédure manuelle simplifiée (v2) pour passer sa base de SQLite à MySQL :

  • Sur le site 1 installé avec SQLite faire une sauvegarde dans tmp/dump/dump1.sqlite
  • Supprimer la meta de structure dans dump1.sqlite :
    echo "delete from spip_meta where nom='dump_structure_temp';" | sqlite3 dump1.sqlite
  • Installer un site 2 avec MySQL avec tous les mêmes plugins actifs (mêmes tables dans la base de donnée)
  • Importer le dump1.sqlite dans le site 2 sous MySQL depuis l’interface SPIP.

Autre solution (signalée par G.Vincent ) : voir http://stackoverflow.com/a/13365275 (nécessite Python).

Autre Solution : passer par le plugin Adminer. [Gilles]

  1. Exporter via Adminer tout le premier site SQLite en ne prenant QUE les données
  2. Créer le site sous MySQL, déplacer le contenu (plugins, squelettes et IMG), activer les mêmes plugins que sur le site d’origine (dont Adminer)
  3. Adminer ajoute des guillemets double (anglais) autour des champs, il faut donc les virer dans le dump téléchargé à l’étape 1). C’est plus ou moins compliqué (dans mon cas c’était simple car je n’en avais pas dans mon contenu).
  4. Pour ne pas toucher aux données qui sont déjà dans la nouvelle base, j’ai choisi de remplacer tous les INSERT INTO par des INSERT IGNORE INTO : cela permet de s’assurer par exemple que l’auteur n°1 est bien celui qui a été créé lors de l’installation mysql
  5. Importer dans mysql. Ca peut se faire dans Adminer, mais si le fichier est gros, on a intérêt à passer par l’excellent script BigDump.php
  6. J’ai eu une fois des doublons dans la liste des plugins : il a suffit de supprimer le dépôt des plugins, puis de le recharger pour que ça fonctionne
  7. J’ai aussi eu des problèmes d’encodage. Mais c’était lié au fichier de dump que je n’avais pas reconverti en utf8 dans Notepad++. Le meilleur moyen pour ne jamais avoir ce problème est d’utiliser le copier-coller du fichier dump dans une requête SQL d’Adminer.

Autre solution (manuelle)[YannX]
-  à partir d’une sauvegarde SQlite traditionnelle récupérée
-  ouvrir le fichier SQLite avec DB Browser for SQLite /Windows
-  Fichier / Exporter / Base de données vers un fichier SQL...
conseil : faire deux exports de fichiers, pour le schema, puis pour les data
-  modifier le fichier SQL (texte ASCII) pour :
-* retirer la ligne n°1 BEGIN TRANSACTION ;
-* remplacer les «  [1] par des ` (AltGr 7),
-* effacer les COLLATE NOCASE
-  importer le fichier corrigé par PhpMyAdmin / Adminer
La syntaxe des Auto-Increments et les index ne sont pas regénérés.