Bonjour.
48 heures, sans affichage normal.
Suite à plantage.
Cherche réparer les tables de site
https://tinyurl.com/yd88llyo
hébergé chez ovh,
j’ai accès à la base PHP et fait une réparation qui n’a rien donné.
Merci de toute, une approche.
Bonjour.
48 heures, sans affichage normal.
Suite à plantage.
Cherche réparer les tables de site
https://tinyurl.com/yd88llyo
hébergé chez ovh,
j’ai accès à la base PHP et fait une réparation qui n’a rien donné.
Merci de toute, une approche.
Bonsoir,
j’ai eu le même problème avec spip 3.2 avec deux sites chez OVH. les bases sont probablement sous MySQL et pas PHP. Avec PhpMyAdmin, j’ai pu réparer correctement la plupart de mes tables sauf une (et, bien entendu, c’est celle qui m’est le plus utile.
Je crois (mais je n’en suis pas certain) qu’il s’agit du remplacement d’une ancienne version de MySql plus maintenue par OVH qui a créé le problème.
Je pense de plus en plus que ce n’est pas suite à un plantage (j’en étais persuadé au début) que l’encodage a dysfonctionné : le plantage est plutôt la conséquence du dysfonctionnement.
Avec PhpMyAdmin, j’ai découvert que les deux bases n’était plus en iso-8859 mzid en latin1… Mes maladroites tentatives de réparation (je ne maîtrise ni MySql ni Php) du début ont malheureusement trop consolidé cet encodage défectueux sur l’une des premières tables traitées.
Bon courage pour la remise en état.
Salut.
Je ne suis pas webmaster.
juste bidouilleur.
Donc c’est l’hébergeur qui remplace son système.
merci, au moins une idée.
Le sam. 23 mai 2020 à 20:51, Nacer-Eddine Boukhari <boukharinacereddine@gmail.com> a écrit :
Bonjour.
48 heures, sans affichage normal.
Suite à plantage.
Cherche réparer les tables de site
https://tinyurl.com/yd88llyohébergé chez ovh,
j’ai accès à la base PHP et fait une réparation qui n’a rien donné.Merci de toute, une approche.
il me semble que c’est un spip 1.9 de mémoire comparer entre le spip 1.9 de OVH et le travail réalisé bénévolement par l’association sur le passage en 3.2.7 ici