Une note a été ajoutée pour ce bug.
http://www.spip.net/bugs/view_bug_page.php?f_id=0000128
Rapporteur: quinton
Responsable:
Projet: SPIP
Bug ID: 0000128
Catégorie: espace public
Reproductibilité: impossible à reproduire
Sévérité: majeur
Priorité: normale
Etat: nouveau
Date de soumission: 22/09/03 09:22 CEST
Dernière modification: 10/10/03 12:52 CEST
Résumé: message erreur : requete SQL
Description:
cette erreur apparait de maniere inexplicable et aléatoire, difficile de
trouver le pourquoi du comment ; toujours est-il que la requete est
valide. Est-ce le code de retour de Mysql qui est mal géré ?
concretement dans cette boucle, je souhaite afficher le dernier article
situé dans une rubrique éditorial ; le code SPIP est apres.
<BOUCLE_principale>
Erreur dans la requête envoyée à MySQL :
SELECT rubriques.* FROM spip_rubriques AS rubriques WHERE rubriques.titre
REGEXP 'editorial' AND rubriques.statut='publie'
</BOUCLE_principale>
<B_principale>
<BOUCLE_principale(RUBRIQUES){titre == editorial}>
<BOUCLE_articles(ARTICLES){id_rubrique}{0,1}{par date}{inverse}>
<?php box_start('box', 'Editorial', 'screw1.gif'); ?>
[ (#TEXTE|justifier) ]
[ <a href="#URL_ARTICLE" title="voir l'édito">...</a> ]
<?php box_close(); ?>
</BOUCLE_articles>
</BOUCLE_principale>
=======================================================================
-----------------------------------------------------------------------
quinton - 22/09/03 10:04 CEST
-----------------------------------------------------------------------
la procédure de gestion des erreurs appelée est : inc-debug-squel.php3 -
erreur_requete_boucle()
il serait interessant de mettre dans un fichier de log le stack
d'execution (.
debug_print_backtrace, debug_backtrace)
le contexte d'appel semble etre le suivant inc-calcul-squel.php3:
//
// Ecrire le code d'envoi de la requete, de recuperation du
nombre
// de resultats et de traitement des boucles par parties (e.g.
1/2)
//
$texte .= ' $query = "'.$requete.'";
$result = @spip_query($query);
if (!$result) {
include_local("inc-debug-squel.php3");
return erreur_requete_boucle($query,
$instance->id_boucle);
}
je me demande dans quelle mesure on a la garantie dans un contexte
d'application concurentielle, que l'erreur affichée et l'erreur réelle
sont les memes. Mon site est un site intranet qui demarre, il ne devrait
pas rencontrer des gros problemes de concurence, mais qui sait ... j'ai un
peu du mal a expliquer cette erreur en parcourant le code.
-----------------------------------------------------------------------
quinton - 22/09/03 10:53 CEST
-----------------------------------------------------------------------
tant que le cache n'est pas effacé, l'erreur reste affichée. Si on force le
rechargement, l'erreur disparait.
il serait souhaitable que les pages générant des erreurs ne soient pas
cachées. Je ne sais pas si c'est le cas. Faudrait invertiger un peu plus.
-----------------------------------------------------------------------
quinton - 22/09/03 12:55 CEST
-----------------------------------------------------------------------
meme erreur sur une boucle hierarchie ; la requete SQL est valide.
j'utilise SPIP 1.6, le systeme de fichiers est local, PHP Version 4.2.2,
mysql client-api
3.23.52, le paquet mysql : mysql-3.23.52-3 ; c'est une redhat 8.0.
j'ai sauvegardé le contenu du cache ; je vais pouvoir comparer par la
suite.
cette erreur existe depuis le debut ou j'ai commencé les developpements de
squelettes, mais je n'avais pas le temps de la traiter ; mais maintenant,
me voila au pied du mur.
<BOUCLE_rubrique_hierarchie>
Erreur dans la requête envoyée à MySQL :
SELECT rubriques.* FROM spip_rubriques AS rubriques WHERE
rubriques.id_rubrique='137' AND rubriques.statut='publie'
</BOUCLE_rubrique_hierarchie>
le code de la boucle est :
<BOUCLE_rubrique_hierarchie(RUBRIQUES){id_rubrique}>
<a href="sommaire.php3">Accueil</a> »
<BOUCLE_chemin2(HIERARCHIE){id_rubrique}>
<a href="#URL_RUBRIQUE" [title="(#DESCRIPTIF|textebrut|entites_html)"]>
[(#TITRE|rubriques_sans_num)]</a> »
</BOUCLE_chemin2>
<a href="#URL_RUBRIQUE" [title="(#DESCRIPTIF|textebrut|entites_html)"]>
[(#TITRE|rubriques_sans_num)]</a>
</BOUCLE_rubrique_hierarchie>
édité le: 22/09 12:50
------------------------------------------------------------
j'ai bien un fichier caché qui contient l'erreur ; le probleme est
qu'il est caché.
-bash-2.05b$ cat CACHE-debug/c/_box_hierarchie-137.b8001c
<!-- debut : _box_hierarchie.html -->
<?php
// porte le nom de _box, mais il n'y a pas de boite
?>
<div style=" text-align: center; font-size: 12pt; font-weight: bold;">
<tt><br><br><blink><BOUCLE_rubrique_hierarchie></blink><br>
<b>Erreur dans la requête envoyée à MySQL :</b><br>
SELECT rubriques.* FROM spip_rubriques AS rubriques WHERE
rubriques.id_rubrique='137' AND rubriques.statut='publie'<br>
<font color='red'><b>> </b></font><br>
<blink></BOUCLE_rubrique_hierarchie></blink></tt>
<?php
if ($GLOBALS['spip_admin']) {
include_ecrire('inc_presentation.php3');
echo aide('erreur_mysql');
} ?><br><br>
</div>
<!-- fin : _box_hierarchie.html -->
édité le: 22/09 12:55
-----------------------------------------------------------------------
antoine - 22/09/03 13:52 CEST
-----------------------------------------------------------------------
Est-ce que tu as essayé de lancer la requête séparément dans un client
MySQL ?
-----------------------------------------------------------------------
quinton - 22/09/03 14:24 CEST
-----------------------------------------------------------------------
oui, antoine, la (les) requetes fonctionnent parfaitement !
ca donne en simplifiant :
mysql> SELECT rubriques.id_rubrique, titre, id_parent FROM spip_rubriques
AS rubriques WHERE rubriques.id_rubrique='137' AND
rubriques.statut='publie';
+-------------+--------------+-----------+
| id_rubrique | titre | id_parent |
+-------------+--------------+-----------+
| 137 | 240 - 7D-CIC | 0 |
+-------------+--------------+-----------+
-----------------------------------------------------------------------
filou - 22/09/03 23:27 CEST
-----------------------------------------------------------------------
Je pense que c'est MySQL qui déconne, mais c'est vrai que SPIP pourrait :
- mieux loger l'erreur (dans son spip.log par exemple)
- ne pas mettre la page en cache
-----------------------------------------------------------------------
antoine - 24/09/03 15:02 CEST
-----------------------------------------------------------------------
Il y a une variable $mysql_debug dans inc_version.php3. Tu peux l'activer
et cela t'affichera les erreurs de façon plus détaillée (j'espère).
-----------------------------------------------------------------------
quinton - 10/10/03 12:52 CEST
-----------------------------------------------------------------------
j'ai encore cette erreur, mais cette fois, vers midi, souvent c'etait le
matin, au x aurores quand SPIP et le serveur redemarrait, a moins que ce
soit les caches qui s'effacent doucement ...
- c'est SPIP 1.6, mais cela arrive aussi en version de dev (1.7.xxx)
- je ne peux pas reproduire cette erreur qui survient de maniere
incontrolable.
- j'utilise fortement le niveau d'include (<inclure())
- pour simplifier, j'ai créé un squelette simple qui n'ouvre que le
squelette
generant l'erreur (pas un inclure) et dans ce contexte simple, l'erreur
reste, en forcant le cache , tout revient dans l'ordre.
- autre chose etrange, quand j'ai cette erreur dans le sommaire, si je
reclic
sur sommaire, cela a tendance a veroller en cascade les différents
includes de mon sommaire, qui a cette forme (en simplifié):
- le probleme c'est qu'il existe un fichier généré qui contient un message
d'erreur et qui reste en cache, il faudrait, faire en sorte qu'au
prochain
rechargement il ne reste pas en cache. Et la ca serait plus cool, parce
que
je ne suis pas sur que mes utilisateurs sachent forcer le cache SPIP. J'ai
implémenté un systeme avec shift-realod qui force le cache a etre
rechargé,
dans mes_fonctions.php (j'agis uniquement sur $delais).
<INCLURE (_header_full.php3)>
<INCLURE (_top.php3)>
<INCLURE (_box_edito.php3)>
<INCLURE (_box_dernieres_breves.php3)>
<INCLURE (_box_la_une.php3)>
<INCLURE (_box_derniers_articles.php3)>
<INCLURE (_bottom.php3)>
voici quelque examples (2) de requettes qui donnent soit disant des
erreurs SQL, alors qu'elles sont valides :
<BOUCLE_principale>
Erreur dans la requête envoyée à MySQL :
SELECT mots.* FROM spip_mots AS mots WHERE mots.titre<>'kawax' AND
mots.titre REGEXP 'A la une'
(message d'erreur provenant de Mysql abscent)
</BOUCLE_principale>
<BOUCLE_articles>
Erreur dans la requête envoyée à MySQL :
SELECT
articles.id_article,articles.id_rubrique,articles.id_secteur,articles.surtitre,articles.titre,articles.soustitre,articles.date,articles.date_redac,articles.date_modif,articles.visites,articles.popularite,articles.statut,articles.accepter_forum,articles.texte
FROM spip_articles AS articles WHERE articles.id_article NOT IN (0) AND
articles.statut='publie' ORDER BY articles.date DESC LIMIT 0,9
(message d'erreur provenant de Mysql abscent)
</BOUCLE_articles>
si je provoque volontairement une erreur, il y a ce genre de message, on
l'on peut voir l'erreur SQL, alors que sur les autres, il n'y a pas
d'erreur :
<BOUCLE_principale>
Erreur dans la requête envoyée à MySQL :
SELECT rubriques.* FROM spip_rubriques AS rubriques WHERE
rubriques.statut='publie' ORDER BY rubriques.nom
Unknown column 'rubriques.nom' in 'order clause'
</BOUCLE_principale>
- si je force le vidage du cache, ca repart parfaitement bien.
- je ne sais pas sur quoi investiguer.
- dans le code, j'avais vu des controls d'erreurs de ce type
$res = spip_query();
if($res == FALSE)
- j'aurais tendance a ecrire === FALSE parce qu'il y a un controle de type
plus fort. Dans le premier cas, 0 peut etre un resultat retourné, mais
différent de false. mon probleme est sans doute ailleurs, mais c'est une
idée.
pour illustrer, c'est ce bout de code qui est généré dans le squelette ou
je provoque volontairement l'erreur :
$retour = "";
$query = $instance->requete;
$result = @spip_query($query);
// ici, c'est pas tres bon ! une requete qui retourn vide, ou 0
doit etre considérée comme une erreur, non ?
if (!$result) {
....