Bonsoir,
Je sais que ce n’est pas trop un forum PHP/MySQL mais comme je ne sais pas trop d’où peux venir le problème, je le poste ici on ne sait jamais
Donc voilà les logs que j’ai au niveau de l’insertion
080110 18:59:29 32 Connect root@localhost on testcommit
32 Query SET AUTOCOMMIT=0
32 Query DESCRIBE `user`
32 Query INSERT INTO `user` (`user`) VALUES ('toto')
32 Quit
Ici on peux voir qu’une insertion est envoyé mais qu’elle n’est pas affecté à la base car aucun COMMIT n’a été envoyé. Il y a un ROLLBACK implicite.
Or le soucis que j’ai c’est que je ne désactive pas l’autocommit dans mon code ou en tout cas je n’ai pas trouvé ou c’était fait.
Est-ce que cela pourrait venir d’une conf quelques parts ou c’est moi qui disjoncte complètement.
Merci, je viens de vérifier mais malheureusement l’option est bien commenté ça ne viens donc pas de là. J’ai essayé en activant l’option et en la mettant à Off, mais cela est resté sans effet.
Je ne sais pas trop d’où ça vient et ça me bloque énormément pour la suite de mon dev fait chier cette connerie :s
Si, dans tes commandes SQL, ou dans ton fichier de config tu forces un AUTOCOMMIT à off, tu dois faire un COMMIT pour que tes changements de l’INSERT soient réellement effectués et visibles par tous les utilisateurs de ta bdd.
SET AUTOCOMMIT=0;
INSERT INTO `user` (`user`) VALUES ('toto');
COMMIT;
Tant que tu ne fais pas ton COMMIT, user ne sera mis à ‘toto’ que pour ta transaction. Mais pas en dur dans ta table.
Si tu veux que ton INSERT ou UPDATE ou autre instructions SQL s’exécutent directement comme pour les tables MyIsam, tu dois mettre AUTOCOMMIT à on (=1). Mais alors, plus de rollback possible.
Merci Ripat je sais bien mais le problème viens du fait que je n’ai jamais demandé un quelconque set autocommit=0 c’est un comportement qui ne devrait pas avoir lieu
Pour remplir ma base le fait d’envoyer un commit apres le permet bien mais je ne cherche pas à avoir se comportement mais juste virer ce set autocommit=0 qui me pourrit mon code.
Tu as faits des modifications particulières concernant ton installation pour que l’autocommit passe à 0 ? C’est vachement étrange ton truc …
Sinon tu peux toujours t’ammuser a placer tes requetes dans des transactions mais ca alourdit pas mal et pour rien on va dire
Par contre j’ai pas tout suivi : la conf de php c’est juste des options qui vont être spécifiques à php donc même si on trouve une solution dans un fichier du genre “php.ini” ca sera, au mieux une rustine :-\ Après pourquoi el comportement par défaut s’est fait la valise …
Qu’est-ce que te renvoie, une fois loggé dans une session mysql :
select @@autocommit;
?
Si ca te renvoie 0 c’est ptet bien que l’ajustement à faire est au niveau des tables d’options de mysql, plutot qu’au niveau d’un fichier de conf (rien trouvé sur autocommit dans mes fichiers de conf personnellement, mais j’ai ptet mal cherché), et y’a des chances pour que ca soit les réglages de mysql qui prévalent sur d’autres options si ces réglages sont plus restrictifs (pure spéculation mais je me dis que ca serait pas complètement bête ).
Apparament une des solutions serait de taper
SET autocommit=1
lors d’une session mysql (par contre je ne sais pas si c’est permanent).
Concernant la modif dans le fichier de conf j’ai trouvé ca sur le net :
Donc il faut bien vérifier que l’utilisateur qui manipule ta BD n’ait pas le privilège SUPER sinon ton réglage n’est de toute façon pas pris en compte.
Voila j’espère que j’ai pas répondu à côté et que ca peut aider =)
Bon ben vérification faites apparemment la config n’entre pas en jeu ici peu importe la valeur de l’option j’ai toujours ce set autocommit=0.
Il me reste à comparer les versions des outils que j’utilise avec ceux de mon patron qui chez lui tout fonctionne.
Je verrais aussi pour qu’il refasse les meme manips que celles que j’ai faites voir si ça fonctionne toujours aussi bien sur sa machine.
Merci pour vos idées de recherches pour la plupart je n’y avais pas pensée. J’ai revérifié maintes fois mon code mais visiblement rien à ce niveau là. Je commence à ne plus rien comprendre.
J’ai réinstallé mysql
j’ai réinstallé phpmyadmin
j’ai revérifié le code source.
Une info qui pourrait peut-etre aidé j’ai mes tables qui sont du type innodb. Est-ce que cela pourrait jouer?
Merci pour ton complément d’info Hoshin. J’y regarde demain et je vous tiens au courant
De toutes façons si tu te bornes à entrer / consulter des données dans une base avec SQL t’as peu de chances de modifier les options donc ton code a peu de chances d’être en cause.
M’enfin si même après réinstallation ca marche toujours pas ca me scie moi .
Donne nous des nouvelles
J’avais effectivement mal compris compris ton pbl. Lu trop vite.
Je vais essayer de rattraper le coup! Alors oui, le type de table est important. Si les tables chez ton boss sont du type non-transactionnel comme MyIsam, pas de COMMIT ROLLBACK etc… Une modification de table est imputée directement.
Si, chez toi tes tables sont transactionnelles (innodb) et que tu veux réutiliser le même code que pour des tables MyIsam, tu dois effectivement forcer la variable d’environnement AUTOCOMMIT à 1.
Ça se passe dans le fichier de config /etc/mysql/my.cnf où tu peux rajouter la ligne suivante dans la section [mysqld]
Redémarrer mysql, un /etc/init.d/mysql force-reload devrait suffire.
Vérifier la valeur par défaut en console (session mysql):
Mais attention: comme précisé plus haut, AUTOCOMMIT ne sera à 1 que pour les connexions d’utilisateurs ne disposant pas des droits SUPER dans la table mysql.user. Donc, si tu ouvres une connexion mysql depuis ton code PHP avec un super-user, je pense que ça ne marchera pas. De toutes les façons, c’est une mauvaise habitude que de donner les super-droits à un utilisateur. Surtout avec PHP et tous les risques d’injection SQL qu’on connait. Si un type réussi à t’injecter du SQL dans un formulaire PHP et qu’il dispose des super-droits, il a la main et ta bdd est morte!
Encore merci pour vos aides et explications mais je dois être maudit
Je me souviens qu’il y a peu cela fonctionnait correctement car j’ai réussi à entrer des données via un script assez simple. Les modifs qui ont été faites entre temps sont faites depuis si longtemps que je ne pourrais vous dire. Mais je sais une chose c’est que je n’ai pas modifié la conf de php.ini et my.cnf avant hier pour les tests. Je ne pense donc pas que ça vienne finalement de là.
J’ai rajouté le set autocommit=1 dans mon fichier de conf mysql et lorsque je renvois la requête j’obtiens
080111 9:05:25 67 Connect user@localhost on user
67 Query SET autocommit=1
67 Query SET AUTOCOMMIT=0
67 Query DESCRIBE `articles`
67 Query INSERT INTO `user` (`content`) VALUES ('toto')
67 Quit
68 Connect user@localhost on user
68 Query SET autocommit=1
68 Query SET AUTOCOMMIT=0
68 Query DESCRIBE `articles`
68 Query INSERT INTO `user` (`content`) VALUES ('toto')
68 Quit
080111 9:13:37 70 Connect root@localhost on user
70 Query SET AUTOCOMMIT=0
70 Query DESCRIBE `user`
70 Query INSERT INTO `user` (`content`) VALUES ('toto')
70 Quit
71 Connect root@localhost on user
71 Query SET AUTOCOMMIT=0
71 Query DESCRIBE `user`
71 Query INSERT INTO `user` (`content`) VALUES ('toto')
71 Quit
[code]mysql> select @@autocommit;
±-------------+
| @@autocommit |
±-------------+
| 1 |
±-------------+
1 row in set (0.00 sec)
mysql>
[/code]Et pour confirmer, les tests j’ai effectué ces tests avec l’user root et un user spécifique qui n’avait que les droits d’usage sur la base de données. Et j’obtiens la même chose à la différence près que le set autocommit=1 n’est pas effectué si je suis connecté en tant que root ce qui confirme
[quote]De toutes les façons, c’est une mauvaise habitude que de donner les super-droits à un utilisateur. Surtout avec PHP et tous les risques d’injection SQL qu’on connaît. Si un type réussi à t’injecter du SQL dans un formulaire PHP et qu’il dispose des super-droits, il a la main et ta bdd est morte![/quote]Je suis d’accord, en prod mes users n’ont que le strict minimum mais en dev en général je me met tous les droits histoire de me faciliter la tache ceci dit je devrais peut être tout restreindre quand même
Bon ben comme c’est la fête et que ça ne viens pas de la config ni du code source, je me suis dit de revérifier encore une fois mes sources. Mais non toujours pas d’autocommit en vue. Et pour venir d’ailleurs ça doit être la vérité
Autres infos qui celle-ci me fait moins plaisir, apparemment ça viendrait du code mais la comprends plus rien.
mysql_connect("localhost", "root", "pass");
mysql_select_db("user");
mysql_query("INSERT INTO user VALUES('', 'toto', 'pass')");
mysql_close();Fonctionne alors que juste derrière je refais la même chose mais différemment et ça ne fonctionne pas. Problème de code je dirais.
Enfin trouvé Nous avons passé une matinée sur un ; c’est super.
Donc en fait dans un fichier ini qui était parsé par zend_config il y avait une option avec un champ vide. Logiquement, il ne devrait rien faire mais ce n’est pas le cas il prend l’option et fou la merde.
Non c’était dans mon code source le soucis. En fait le problème viens de l’interface Zend Framework. PHP et MySQL n’ont rien à voir dans l’histoire.
En fait dans un fichier de config ini pour Zend, j’ai mis l’option config.driver_options = et je ne lui affecte pas de valeur n’en n’ayant pas besoin. Cette option existe suite à l’utilisation d’un squelette.
Cette option est parsée et transtypée comme la valeur est une chaine vide alors le transtypage nous donne un array(0 => ‘’); qui lui est bien compris par PDO.
Le problème viens donc du fait que le transtypage ici explicite n’est pas correctement filtré.
Si vous n’utilisez pas Zend Framework, pas de problème pour vous sinon, ben faudra attendre la prochaine release avec la correction de ce bug qu’on a soumis
Zend/Db/Adapter/Abstract.php ligne 191 remplacer le array_key_exists par un !empty
mais comme je ne sais pas trop d’où peux venir le problème, je le poste ici on ne sait jamais 
.