Désolé du temps de réponse.. Effectivement j'ai un error_reporting à E_ALL mais pourtant pas d'erreur.. Le traitement PDO peu parfois durer 1 min, je ne sais pas si ça a une influence sur le fait que PHP peu perdre le cours de son exécution.

Mais dans l'absolu ça n'est pas l'arrêt de PHP qui me pose problème, c'est plus que je n'arrive pas à capter l'erreur PDO (même avec try...catch) parce qu'en fait pour lui, il n'y a pas d'erreur ! le résultat de mon 'execute' me renvoit 1 comme si l'exécution de ma procédure était terminé et s'était bien passé..

Je commence à baisser les bras... :cry:

tu codes avec du error_reporting E_ALL? parceque si php s'arrête tu devrais avoir une erreur affichée au moins.

Bonjour,

Je me décide à poster mon problème, car après plusieurs jours de recherche, même sur ce fabuleux forum de PHPFrance :D, je n'ai pas trouvé réponse à mon souci.

Voilà, j'arrive à exécuter les procédures stockées grâce à PDO, avoir des paramètres d'entrée/sortie, etc. mais mon problème vient des retours qui ne sont pas placés dans une variable à la manière de :
[code]
SELECT MaColonne INTO v_tmp ...
.....
RETURN v_tmp
[/code]
Pour être plus clair, dans la société dans laquelle je travaille, je m'occupe de l'interface en php d'une sorte d'appli web et mon collègue plus de la base MySQL. Mon collègue utilise de temps en temps des SELECT sans INTO pour débugger ses procédures stockées afin d'afficher dans sa console DOS quelques infos.

Pour moi cela pose un vrai problème car j'ai l'impression que PHP interprète cela comme un retour et donc considère le traitement de la procédure stockée terminée.. Mais le plus étrange est qu'il ne poursuit même plus le reste de traitement PHP...

Je suis sur que mon problème vient de ces SELECT car en les retirant tout fonctionne, mais du coup c'est mon collègue qui galère. Bien sûr, on a déjà pensé retourner tous les SELECT dans des variables et les faire remonter à la fin du traitement, mais cela nous laisse beaucoup moins de souplesse..

Merci de votre aide !

Jérémy