Discussion :

[Ldoppea]

Bonjour,

Je cherche à savoir, lors d'une exception sur une requête LINQ, si l'exception est due à une perte de connexion avec la DB ou autre chose.

J'ai vu dans la doc msdn qu'il y a un level code qui permet de savoir la gravité de l'exception, mais je n'arrive pas à savoir lequel correspond à une perte de connexion.

Aussi pendant le développement du projet, la bdd se trouve dans la solution VS, et donc sur mon ordinateur. Donc impossible de simuler une perte de connexion en déconnectant l'ordinateur.

Voici donc mes question :

Est-il possible de connaitre l'état d'une connexion (avec ou sans aide d'exception)?
Est-il possible de simuler la perte de connexion depuis le code?

Merci d'avance

[randriano]

Je ne préconiserai que l'utilisation de "try ... catch ... end try" autour de chaque portion de code lisant/écrivant dans la DB

Est-il possible de simuler la perte de connexion depuis le code?

[Invité]

Est-il possible de connaitre l'état d'une connexion (avec ou sans aide d'exception)?

en utilisant monDataContext.Connection.State (ou mondDataContext correspond au n om de ton contexte de donnée).

Est-il possible de simuler la perte de connexion depuis le code?

Oui. en appellant la méthode monDataContext.Connection.Close() dans un autre thread.

[Ldoppea]

Ah je viens seulement de voir vos réponses

En attendant j'y étais allé bourrin en coupant le service SQL Server pendant l'exécution du code

h2s84 : je vais essayer cette méthode et je vous tiens au courant

[Jérôme Lambert]

Tu as aussi la possibilité d'être notifié lorsque l'état de connexion de l'objet SqlConnection change grâce à l'événement StateChange.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
public void Init()
{
    Core.Application.DataContext.Entities.Connection.StateChange += new StateChangeEventHandler(Connection_StateChange);
}
 
void Connection_StateChange(object sender, StateChangeEventArgs e)
{
    // e.OriginalState;
    // e.CurrentState;
}

[Ldoppea]

Excellent, ça va résoudre pas mal de mes problèmes (beaucoup plus simple à gérer qu'à attendre qu'une exception se lève ). Même s'il faut quand même garder les try catch, on ne sais jamais.

Merci pour la réponse