Bonjour,
 
J'ai une appli web qui marche très bien en local et dont l'architecture provient d'une autre appli web qui est éprouvée depuis 8 ans sur un serveur de prod en entreprise.
Bizarrement, cette appli, une fois sur un serveur mutualisé d'OVH, de manière a priori aléatoire, les requêtes à partir d'un point aussi a priori aléatoire et jusqu'à la fin de scripts php ne s'exécutent plus.    
Je passe par la lib PEAR:DB pour exécuter mes requêtes SQL. En gros, certains scripts effectuent un certain nb de requêtes et au bout d'un moment dans le script (ce moment étant a priori aléatoire, ça se produit pas au même endroit dans le script ou dans une itération d'une boucle du script), les requêtes ne sont plus exécutées (en tout cas, y'a plus de résultat obtenu). Pourtant, le script php s'exécute jusqu'au bout et j'ai pas de pb de timeout ! Mais dans l'IHM, à l'endroit où je devrais avoir des données provenant de la BD, ben j'ai un blanc
 
En effectuant un debug, je me suis rendu compte que PEAR:DB remontait justement au moment où mes requêtes passent plus qu'il n'y avait plus de bD sélectionnée. Or, ce genre de message d'erreur peut survenir en plein milieu d'un bouche où les itérations précédentes sont bien passées.    
 
Et j'ai beau essayé de détecter ce message d'erreur et relancer une connexion à la BD, j'ai toujours le même problème. J'ai testé cette appli sur plusieurs PC locaux (wampserver), je l'ai testé sur un autre hébergeur gratuit, j'ai aucun pb de ce genre. C'est la première fois que je vois ça ! Et pour l'instant, je peux pas rester chez l'hébergeur gratuit car pas assez de place pour accueillir l'appli avec toute ces données (je parle sur du moyen terme, il propose que 100 Mo d'espace disque) et pour l'instant, j'ai pas d'autre solution qu'OVH en mutualisé comme je suis là (j'étudie une solution de migration vers un autre hébergeur comme 1&1 par ex, mais ça va prendre du temps car y'aurait pas que cette appli à migrer du coup).
 
En cherchant sur le web, j'ai vu que ce pb survenait parfois et que la solution était de bidouiller le fichier de conf de mysql, chose que je ne peux pas faire en mutualisé
 
Du coup, c'est problématique car certains scripts ne s'exécutent pas correctement au niveau SQL, ce qui génèrent qq bugs dans l'appli...
 
Par le plus grand des hasards, ce pb vous dit-il qq chose ?
 
Merci

Il faut vérifier s'il y a des erreurs à la reconnexion également. Il se peut que ce soit le serveur MySQL qui refuse la connexion pour éviter la surcharge, il doit être d'une certaine manière en mutualisé pour éviter le dénis de service. Est-ce que les connexions sont persistantes ? Que se passe-t-il lorsqu'on attend avant une re-tentative (sleep(10)) ?