Bonjour,
 
J'ai un petit souci avec une requete mysql.
Lorsque j'envoie ma requête, je récupère l'exception suivante :
 
{"Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding."}
 
Si je passe ma requete "à la main" via Mysql Query browser elle fonctionne.
Effectivement, elle prends un peu de temps (entre 30 s et 90s) à s'executer vu la complexité et la taille de la base, mais, j'en ai une autre équivalente au temps d'exécution qui elle passe correctement.
 
Auriez-vous une idée pour résouder mon soucis?
 
Voici le code que je lance pour passer mes requêtes :
 
///Execution de la requête
            ///
 
            try
            {
                //com = new MySqlCommand(requete, ConnectionRessource);
                ///On charge le data set avec notre requete
                MySqlDataAdapter mysqlDA = new MySqlDataAdapter(requete, ConnectionRessource);
                mysqlDA.Fill(mysqlDS, "resultat" );
                Thread main = Thread.CurrentThread;
               
            }
            catch (MySqlException myEx)
            {
                using (StreamWriter sw = File.AppendText("C:\\Error" + nomU + ".log" ))
                {
                    Log("ERROR " + myEx.GetType() + " : Impossible d'exécuter la requête suivantes : " + requete, sw);
                    mysqlDS.Tables.Add();
                    sw.Close();
                }
            }
 
Merci d'avance pour votre aide  

conn.ConnectionTimeout = 0;

pas trop d'accord avec le timeout à 0.
 
il n'est pas recommandé de l'utiliser, car en cas de lock sur la table, la requête, qui risque elle-même de faire un lock, ne va jamais expirer, et ainsi on fini par locker l'ensemble de la base et tout planter.
 
il vaut mieux faire un choix, et choisir la plus grande valeur parmis les trois suivantes :
- temps de réponse maximum autorisé (pour une application client/serveur, par exemple, 5 secondes c'est le bout du monde)
- temps d'exécution à partir duquel on estime que la requête sera annulée par l'utilisateur
- interval entre deux lancements de gros traitements succeptibles de provoquer ce comportement
 
=> En effet, pour une GUI "end user", il est important d'avoir un temps de réponse très rapide. au bout de quelques secondes sans résultat, pour une simple consultation par exemple, on estime que l'utilisateur est "autorisé" à jeter son pc par la fenêtre s'il n'a toujours pas le résultat. pour certain types d'application, on utilisera donc un timeout très rapide : il vaut mieux planter proprement et dire à l'utilisateur qu'en raison d'une forte charge, il ne peut pas accéder à la fonction, plutôt que de laisser tourner le truc 15 minutes (et l'empêcher de faire autrechose) avant de péter parceque de toute façon ça doit péter.
=> passé un certain délai, à nouveau, l'utilisateur est en droit de penser que l'application est plantée, et donc tout fermer "sauvagement". il est donc important de préférer produire une erreur propre avant.
=> enfin, pour un gros batch où l'utilisateur sait que ça va durer très longtemps, il faut faire attention. par exemple, un batch qui se lance toutes les heures devra impérativement mettre moins d'une heure à tourner, sans quoi on risque d'exploser le serveur au bout de quelques heures.
 
bref, le "timeout=0" ne répond à aucun de ces trois points. et le dernier est pourtant très important, puisque son non respect peut entraîner un plantage grave du système, et l'impossibilité de travailler pendant un certain temps, voir même des pertes de données (genre sur un système transactionnel, on peut supposer que tout le monde va bloquer au moment du commit parcequ'un lock sur une table les empêche de terminer la transaction... un reboot "intempestif" du serveur pour cause de surcharge -dead locks, etc.- va donc entraîner la perte de toutes les transactions en cours, ce qui peut rapidement correspondre à des volumes importants si l'application est multi-utilisateurs.
 
bref, dans la doc c'est très bien explique.
 
donc pour une requête qui met entre 30 et 60 secondes, on peut mettre arbitrairement un timeout à 120 secondes. cela reste suffisament grand pour garantir que la requête fonctionne dans le cas "normal", mais ça garanti aussi qu'elle ne va pas tourner indéfiniment en cas de problème.

le meilleur exemple, c'est les connexions réseau. un timeout se produit généralement avant 5 secondes. rarement au bout de plus de 30 secondes. quand on ouvre l'explorateur windows et qu'on tape un nom d'ordinateur ou une ip qui n'existe pas, ça cherche dans le vide, l'explorateur est figé... et le timeout est clairement trop long. passé 5 secondes, l'utilisateur lambda va commencer à cliquer partout pour essayer d'ouvrir un autre explorateur, fermer la fenêtre figée, tenter de faire un kill des process, etc. et au final, il risque d'engendrer d'autres tentatives de recherches sur une ip qui n'existe pas, donc devoir attendre d'autres timeout, et ça se termine par un "switch off" direct sur la multi-prise du PC.
 
=> c'est un peu pour ça aussi que joce fait disparaître le bouton "valider votre message" sur le forum. outre le flood, sur une connexion lente, ça peut prendre plusieurs secondes avant d'afficher la page suivante, et l'utilisateur va être tenté de cliquer plusieurs fois sur le bouton... c'est typiquement ce qu'il faut absolument éviter sur une application client/serveur, d'où l'utilité de mettre un timeout suffisament rapide : ça évite d'avoir 25 fois la même requête qui tourne en // sur un serveur effondré parceque l'utilisateur s'est excité sur le bouton

tu m'as convaincu