Le problème est simple, bien que quelque peu aléatoire… depuis que la sauvegarde est passée sous sqlite, je crois n’avoir pas souvent réussi (sur une douzaine au moins de sites SPIP 3.x chez OVH) une sauvegarde complète d’une base SPIP. Encore en milieu de semaine sur SPN : la restauration a zappé totalement la tables ARTICLES … et la table RUBRIQUES La seule solution a été de ré-intégrer “a la mano” par Adminer (merci Suske) de petits bouts du dump SQL que -prudent- j’avais AUSSI fait avec Save_auto Peut-etre que ce souci serait aussi dû à l’implémentation SQlite chez OVH ? (j’avais constaté que l’instalaltion automatique SQlite SPIP créait un MySQL non-accessible ! ) mais il me faudrait demander à Bernard de vérifier sur son serveur kimSufi si c’est également le cas… Je n’ose imaginer un utilisateur moins aguerri…
La demande #3196 a été mise à jour par cedric -.
- *Statut* changé de *Nouveau* à *Fermé*
- *Resolution* mis à *invalid*Bon, faute de description et suite a r21750 / r21752 je ne constate aucun
probleme de backup sur une base avec un prefixe different de 'spip'
------------------------------
Anomalie #3196: Bug (bien connu des anciens) de sauvegarde standard des
q'un prefixe .... <http://core.spip.org/issues/3196#change-10189>- Auteur: YannX spip
- Statut: Fermé
- Priorité: Normal
- Assigné à:
- Catégorie:
- Version cible: 3.0
- Resolution: invalid
- Navigateur:Deux avertissements :
- prévenir que la sauvegarde peut etre incomplète
- préciser le prefixe utilisé "qq.part" dans l'interface
(pour qu'un gestionnaire pas trop expérimenté ne galère pas trop !)Merci
YannX
------------------------------Vous recevez ce mail car vous êtes impliqués sur ce projet.
Pour changer les préférences d'envoi de mail, allez sur
http://core.spip.org/my/accountLe problème est simple, bien que quelque peu aléatoire...
depuis que la sauvegarde est passée sous sqlite,
je crois n'avoir pas souvent réussi
(sur une douzaine au moins de sites SPIP 3.x chez OVH) une sauvegarde
complète d'une base SPIP.Encore en milieu de semaine sur SPN : la restauration a zappé totalement
la tables ARTICLES .. et la table RUBRIQUESLa seule solution a été de ré-intégrer "a la mano" par Adminer (merci
Suske)
de petits bouts du dump SQL que -prudent- j'avais AUSSI fait avec Save_autoPeut-etre que ce souci serait aussi dû à l'implémentation SQlite chez OVH ?
(j'avais constaté que l'instalaltion automatique SQlite SPIP créait un
MySQL non-accessible ! )
mais il me faudrait demander à Bernard de vérifier sur son serveur kimSufi
si c'est également le cas....Je n'ose imaginer un utilisateur moins aguerri...
Et ça ne serait pas dans ton cas un soucis de timeout ? Ou de mémoire ?
vu un rechargement de page, j’apercois bien l’ecran final de SPIP qui m’affiche parfois (0/…) sur certaines tables : donc si c’etait un timeout, ce serait plutot de la base… mais pas dès les premières tables ?? Non, je vais commencer à croire à un conflit d’implémentation MySQL-SQlite chez OVH (si ce n’est un bug dû au préfixe, ou au principe de SQlite…) mais je ne sais déterminer d’ici ! Si cette hypothèse se verifiait (appel a tous les utilisateurs de bases SPIP_préfixées chez OVH ??), cela serait très gênant pour de nouveaux utilisateurs, car tout le monde ne peut pas etre hébergé chez Nursit ! 
Pas la peine de faire tout un ramdam. Je signalais juste dans ton ticket qu’il était incompréhensible, et que tu ne donnais aucun détail pour réproduire le bug. Cela dit de ce que je lis dans tes mails ce matin, c’est sans doute la même chose que http://core.spip.org/issues/3270 et c’est résolu.
Merci de tester et confirmer après mise à jour.
Cédric