SQLSTATE[42000] > 1118 Row size too large ???

kamelzagger
PHP

Bonjour à tous,

J'ai récemment réalisé un site internet pour un client avec un systeme d'administration (afin qu'il puisse modifier son site internet lui même, façon CMS).

Tout le site et l'espace d'administration fonctionnait très bien. J'usqu'a ce qu'il m'appele pour une erreur sur le site. Certains champ ne sont plus modifiables et retournent une erreur. (la même apparement)

Par exemple avec ces champs :

1) sur la page qui permet de modifier le texte de bienvenue...)

Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[42000]: Syntax error or access violation: 1118 Row size too large (> 8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline.' in /home/www/6d355bc22953e6e55ae7fa4f5b6a7da6/web/ecole_bosco/administration/accueil-texte.php:39 Stack trace: #0 /home/www/6d355bc22953e6e55ae7fa4f5b6a7da6/web/ecole_bosco/administration/accueil-texte.php(39): PDOStatement->execute(Array) #1 {main} thrown in /home/www/6d355bc22953e6e55ae7fa4f5b6a7da6/web/ecole_bosco/administration/accueil-texte.php on line 39

2) Page qui permet de modifier le texte de la page maintenance..)

Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[42000]: Syntax error or access violation: 1118 Row size too large (> 8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline.' in /home/www/6d355bc22953e6e55ae7fa4f5b6a7da6/web/ecole_bosco/administration/modif_maintenance.php:52 Stack trace: #0 /home/www/6d355bc22953e6e55ae7fa4f5b6a7da6/web/ecole_bosco/administration/modif_maintenance.php(52): PDOStatement->execute(Array) #1 {main} thrown in /home/www/6d355bc22953e6e55ae7fa4f5b6a7da6/web/ecole_bosco/administration/modif_maintenance.php on line 52

C'est un exemple avec deux champs pris au hasard dans l'espace d'administration. Ce qui est étrange c'est que je dois avoir environ 70 champs dans la bdd et il doit y en avoir une dizaine qui ont ce problème la et comme je l'ai dit , je n'avait pas rencontré ce problème avant.

Quelqu'un aurait un petit coup de pouce pour moi ? :)

18 réponses

Carouge10

Bonjour,

C'est un problème de taille dans la BDD.
Qu'elle est le type des champs ?

kamelzagger
Auteur

Hello Carouge10

Merci pour ta réponse. Oui je pensait bien qu'il y avait une erreur à ce niveau là.

La plupart de mes champs qui ont cette erreur sont actuellement en type TEXT (Sans limite donc), j'ai aussi essayé d'autre type comme varchar ou blob (comme l'erreur le proposait) mais sans succès...

Carouge10

Alors non, le type text n'est pas sans limite.

Type = Taille Maximale
CHAR = 255
VARCHAR =255 (65 535 à partir de MySQL 5.5)
TINYBLOB, TINYTEXT = 255
BLOB, TEXT = 65 535
MEDIUMBLOB, MEDIUMTEXT = 16 777 215
LONGBLOB, LONGTEXT = 4 294 967 296

Source : OpenClassRooms

kamelzagger
Auteur

Alors si je comprend bien TEXT est limité à 65 535 mais sa n'explique pas l'erreu que je rencontre car j'insérer en moyenne une centaine de caractère par champ pas plus.. (Parfois un peu plus certe mais sa ne dépasse jamais les 500).

Carouge10

Je ne suis pas spécialiste en mysql.
Par contre, ce que je sais, c'est que quand vous ajoutez une image à ce texte. C'est le lien qui est enregistrer et donc cela augmente ça taille, sans oublier les balises html.
Si votre client rentre beaucoup d'élément dans ce TEXT, cela peut se comprendre qu'il arrive à sa limite.

Il y a aussi les caractère spéciaux ( é, è, à ...) qui prennent plus de place. Le utf8 prend aussi de la place.

Huggy

Cela peut venir de la variable innodb_log_file_size qui est sous-dimensionnée
il faut la dimensionner à au moins 10 fois la taille du plus gros BLOB plus les tailles des champs varchar, text ...
voir cet article
par défaut innodb_log_file_size vaut 48Mo

Carouge10

A essayer, je n'ai pas rencontré ce problème à ce jour.

kamelzagger
Auteur

merci pour vos reponses.
en effet le texte qui est inserer est de l'html et les balise augmentent relativement ma longueur.

Mais que puis je faire pour eviter cette erreur ?

hugy merci pour ta proposition mais comment dois je faire cela ?

merci a vous

Huggy

Il suffit de modifier la variable ou de la créer dans le fichier my.ini (my.cnf sous Linux)

innodb_log_file_size = 75M

Avec phpMyadmin, dans la section 'variables' on peut contrôler que la valeur a bien été prise en compte

kamelzagger
Auteur

Merci pour ta réponse mais ou se trouve le fichier my.ini ? Pour info je suis sous MAMP avec MAC.

J'ai regardé du coté de phpMyadmin et pour le moment la variable innodb_log_file_size à la valeur suivante : 5242880

Huggy

Il semble (mais à confirmer) qu'avec MAMP (pas pro) il n'y ait pas de my.cnf par défaut
il faut le créer dans "/Applications/MAMP/conf/"
voir ici
Pour la valeur 5242880, ça ne fait que 5MB , t'as pas oublié un chiffre ?

kamelzagger
Auteur

dacc ca marche je vais tester ca plus tard, merci beaucoup !

non cest bien ce que jai comme chiffre.

kamelzagger
Auteur

Ha mais j'y pense, cette solution change la valeur de la variable sur le phpmyadmin local. Moi j'ai besoin de faire ce changement sur le serveur du site du client (car il est deja en ligne..), es ce que tu sait si il y à une solution direct depuis phpmyadmin ? Ou autre ?

Huggy

La modification de cette variable nécessite un redémarrage du serveur.
Si tu es en mutualisé, tu n'y auras de toutes façons pas accès
Pas moyen de modifier la variable par un SET ... dans une commande, il faut modifier le fichier de conf

kamelzagger
Auteur

Je suis en mutualisé oui. Mais pas très bien compris, tu veux dire qu'il n'y à pas de solution si je suis en mutualité ?

Huggy

Si tu es chez OVH il y a une option payante 'Mysql privé' sur les hébergements 'pro'
je n'ai pas testé

kamelzagger
Auteur

Non le client n'est pas sur OVH mais sur un serveur suisse qui traite avec infomaniak. A la limite faudrait que je regarde directement avec eux.

kamelzagger
Auteur

Comme je ne peux pas les contacter ces jours (ascension), qqun aurait une solution miracle en attendant (ou définitive, ce serait encore mieux !) ?

Merci à vous