IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Bases de données Delphi Discussion :

Obtenir un état précis de la connection SQL sans bloquer le système


Sujet :

Bases de données Delphi

  1. #1
    Futur Membre du Club
    Profil pro
    Inscrit en
    Décembre 2006
    Messages
    9
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2006
    Messages : 9
    Points : 5
    Points
    5
    Par défaut Obtenir un état précis de la connection SQL sans bloquer le système
    Bonjour,

    Mon soucis est simple : un fois connecté à ma base, comment détecter une perte réseau ou un problème sur le serveur SQL sans bloquer le système ou utiliser inutilement trop de ressource ?

    Je me connecte à ma base sous Delphi en utilisant un objet TSQLConnection. Comme il s'agit d'une connection à travers un réseau, je garde la connection ouverte.
    Une fois connecté, même si je débranche mon réseau, la propriété ConnectionState garde l'état 'Connection Ouverte'.
    Ca ne m'arrange pas, car si je fait une requête SQL à ce moment, le bloquage dû au timeout peut être long ...

    Aujourd'hui, la base est SQLServer, mais j'aurais aimé trouvé une solution générique. J'ai eu beau fouillé par moi-même ou sur les forums, j'ai rien trouvé. Pourtant, ce doit être une problématique classique pour les solutions client-serveur !?

    Quelqu'un aurait-il ça en stock ?

    Merci par avance.

    Joyeuses fêtes à ts le monde

  2. #2
    Membre actif
    Profil pro
    Inscrit en
    Juillet 2003
    Messages
    190
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Juillet 2003
    Messages : 190
    Points : 218
    Points
    218
    Par défaut
    bonjour

    je te propose de mettre un timer qui va faire periodiquement une requete environ 1*10 min

    mettre un evenement sur tapplication.onexception
    ou tu réagirais en fonction de l'exception (si exception BD alors reconnection+message erreur)
    @+

  3. #3
    Futur Membre du Club
    Profil pro
    Inscrit en
    Décembre 2006
    Messages
    9
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2006
    Messages : 9
    Points : 5
    Points
    5
    Par défaut
    Merci pour ta réponse WolffN,

    Actuellement, j'ai déjà un thread dédié à la connection à la base. Ce thread est une boucle dans laquelle je teste la présence du serveur distant à l'aide d'un ping, puis une requête pour vérifier que le serveur est disponible. Seulement, cette requête ne renvoi l'erreur qu'après un timeout de 15 secondes.

    j'aurais aimé quelque chose de plus rapide afin que mon interface ne donne pas l'impression d'être figée : le genre de chose que j'aurais avec des objets comme SQLDMO_TLB pour SQLServer.

  4. #4
    Rédacteur
    Avatar de Giovanny Temgoua
    Profil pro
    Étudiant
    Inscrit en
    Novembre 2003
    Messages
    3 830
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Novembre 2003
    Messages : 3 830
    Points : 4 006
    Points
    4 006
    Par défaut
    Je ne sais pas s'il y'a un moyen de détecter la perte de connexion aussi facilement et la solution d'exécuter une requête à intervalle régulier me semble contraire à
    Citation Envoyé par Bwana
    sans bloquer le système ou utiliser inutilement trop de ressource ?
    Si tu as accès à la machine serveur, une solution plus évidente à mettre en place est d'utiliser un compo "réseau" comme le TClientSocket/TServerSocket; tu as un évènement qui est déclenché en cas de perte de connexion (OnError je crois bien)

  5. #5
    Futur Membre du Club
    Profil pro
    Inscrit en
    Décembre 2006
    Messages
    9
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Décembre 2006
    Messages : 9
    Points : 5
    Points
    5
    Par défaut
    Merci Giovanny,

    Je prend l'idée de l'événement OnError. C'est probablement moins gourmand qu'un ping en boucle. Reste à tester en condition réelle.

    Le seul point qui me reste à vérifier c'est la disponibilité du serveur SQL.
    Mon appli doit se connecter sur un serveur géré par mon client. Je crains de ne pas disposer d'une connection permanente ou fiable. L'inconvénient serait de figer mon appli à chaque fois que l'administrateur du serveur réalise un traitement lourd sur sa base. Je préférerai pouvoir afficher un message du type : 'traitement impossible car le serveur SQL est occupé'.
    (toujours les problèmes de limites de responsabilité ... )

    Je vais laisser ce sujet de discussion ouvert au cas où quelqu'un ai déjà eu cette problématique.

    Et comme je vais justement passer ma dernière semaine de l'année chez ce client , je n'ai plus qu'à vous souhaiter de bonnes fêtes et une bonne année

Discussions similaires

  1. État, Requète et clause Where(SQL)
    Par Philippe299 dans le forum Access
    Réponses: 2
    Dernier message: 12/09/2005, 00h22
  2. [VB.net] Connection SQL server
    Par WriteLN dans le forum Windows Forms
    Réponses: 1
    Dernier message: 19/08/2005, 17h39
  3. Problème de connection à SQL Server
    Par wsangli dans le forum MS SQL Server
    Réponses: 9
    Dernier message: 12/08/2005, 17h19
  4. obtenir un état semestriel et annuel de données trimestriell
    Par AFAT dans le forum Bases de données
    Réponses: 2
    Dernier message: 25/10/2004, 21h25
  5. obtenir un état semestriel et annuel de données trimestriell
    Par AFAT dans le forum Bases de données
    Réponses: 3
    Dernier message: 22/09/2004, 19h28

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo