Bonjour à tous,
j'ai un problème qui me fait péter un plomb depuis plusieurs jours. Plus je cherche, et plus je me dis que c'est bizarre, voire pas normal ...
Alors avant de sombrer dans la paranoïa aigüe, j'en appelle à votre expertise de mysql car je suis désormais convaincu que le, problème vient bien de la BD elle-même :

J'ai une requête d'insertion, toute simple, dont je suis sûr qu'elle ne contient pas d'erreur, dont je suis sûr qu'elle est bien soumise au SGBD par mon code PHP ... et qui n'insère pas ce que je lui demande ... enfin, seulement quand ça lui chante !

Je m'explique :
j'ai dans ma BD deux tables toutes simples, dont voici la déclaration en SQL (export phpMyAdmin) :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
 
-- 
-- Structure de la table `abonnementAlerteMelRSS`
-- 
 
CREATE TABLE `abonnementAlerteMelRSS` (
  `idAlerteMelRSS` int(10) NOT NULL,
  `loginUtilisateur` varchar(64) NOT NULL,
  `dateDernierEnvoi` date default NULL COMMENT 'NULL si jamais envoye',
  PRIMARY KEY  (`idAlerteMelRSS`,`loginUtilisateur`),
  KEY `loginUtilisateur` (`loginUtilisateur`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
 
-- --------------------------------------------------------
 
-- 
-- Structure de la table `alerteMelRSS`
-- 
 
CREATE TABLE `alerteMelRSS` (
  `idAlerteMelRSS` int(10) NOT NULL auto_increment,
  `urlFil` varchar(512) NOT NULL,
  `titreFil` varchar(512) NOT NULL,
  `descriptionFil` tinytext,
  PRIMARY KEY  (`idAlerteMelRSS`),
  UNIQUE KEY `urlFil` (`urlFil`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
 
-- 
-- Contraintes pour les tables exportées
-- 
 
-- 
-- Contraintes pour la table `abonnementAlerteMelRSS`
-- 
ALTER TABLE `abonnementAlerteMelRSS`
  ADD CONSTRAINT `abonnementAlerteMelRSS_ibfk_2` FOREIGN KEY (`loginUtilisateur`) REFERENCES `utilisateur` (`login`) ON DELETE CASCADE ON UPDATE CASCADE,
  ADD CONSTRAINT `abonnementAlerteMelRSS_ibfk_1` FOREIGN KEY (`idAlerteMelRSS`) REFERENCES `alerteMelRSS` (`idAlerteMelRSS`) ON UPDATE CASCADE;
Rien de bien compliqué : la table 'abonnementAlerteMelRSS' a deux clés étrangères dont une pointant sur la table 'alerteMelRSS'.
Pour abonner un utilisateur à une alerte, il faut donc inserer un nouvel enregistrement dans la table 'abonnementAlerteMelRSS'.
Si l'abonnement correspond à une nouvelle alerte (pas encore enregistrée) j'enregistre celle-ci AVANT et récupère son id auto-incrémenté pour pouvoir insérer ensuite l'abonnement avec la bonne clé étrangère ...
C'est donc hyper-simple ...
Il y a donc deux requêtes d'insertion (dont une facultative) qui sont potentiellement générées et exécutées. Exemple : (copiés-collés du code SQL généré par ma couche de persistance en PHP tel qu'envoyé à mysql)
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
-- requête 1 (facultative : seulement si l'alerte n'est pas déjà dans la base)
INSERT INTO alerteMelRSS(urlFil, titreFil, descriptionFil) VALUES('fil-rss-tous-les-documents','enssib - Bibliothèque numérique','Tous les documents de la bibliothèque numérique de l\'enssib')
 
-- requête 2 (systématiquement éxecutée)
INSERT INTO abonnementAlerteMelRSS(idAlerteMelRSS,loginUtilisateur) VALUES ('1','saladin')
J'ai bien sûr testé ces deux requêtes à la main dans phpMyAdmin, et elles sont bonnes (elles sont hyper simple, mais on sait jamais, une faute de frappe).
J'ai aussi vérifié l'id auto-incrément récupéré après la requête 1, il est bon, pas de problème.
D'ailleurs MySQL les accepte sans broncher et ne me retourne aucune erreur.

Problème :
- si j'exécute la requête 1 (dans certains cas seulement), l'exécution de la requête 2 n'a aucun effet, l'enregistrement de l'abonnement n'est pas inseré, et je n'ai pas de message d'erreur (c'est comme si elle était ignorée !)
- si je n'exécute pas la requête 1, la requête 2 passe nickel, ce qui prouve qu'elle est bonne

On dirait que la première requête empêche la seconde d'être exécutée ... POURTANT j'ai essayé de rendre la requête 2 invalide (en glissant volontairement une erreur dedans) et là MySQL me sort une erreur de syntaxe, ce qui prouve :
- que la requête est bien envoyée au SGBD
- que je récupère bien les erreurs émises par le SGBD

Je me demande d'où cela peut venir ... en apparence on dirait un bug étrange de mysql, mais je n'y crois pas trop : c'est trop énorme et puis statistiquement, il y a quand même plus de chances que je me sois planté quelque part ou que j'ai raté un épisode ...

Comme je n'avais aucun message d'erreur, j'ai voulu voir si il y avait quelque chose dans les logs de mysql mais le seul fichier de log que j'ai trouvé (/var/log/mysqld.log) ne concerne que les grands évènements de la vie du daemon mysql (arrets, demarrages, plantages ...). Est-ce qu'il y a d'autres logs plus precis quelque part ?
Comment trouver des indices qui me permettront de remonter la trace de ce phénomène paranormal ?

Si vous avez un tuyau, une idée, si vous avez déjà vu quelque chose ressemblant à ça, ou si vous savez comment exorciser un serveur mysql ...
Merci d'avance !!!

PS : MySQL 5.0.27 sous Fedora Core 6, tables toutes en InnoDB, utilisation d'une couche de persistance basée sur le package PEAR::MDB (mais je suis presque sûr que le problème ne vient pas de là, la vérité est ailleurs ...)