Lancer une action à un moment précis.

Bonsoir,
Je programme en VB.net 2010 et je voudrais pouvoir lancer une procédure à un moment très précis.
Explication : j'ai un automate connecté à un analyseur de gaz qui renseigne toutes les 2 minutes une base de données sous SQLServer 2000. Je veux récupérer en continu le dernier enregistrement de la base de données dès qu'il est disponible. Si j'utilise un Timer dans VB.Net, je crains de ne plus etre synchro au bout d'un moment. Je voudrais savoir s'il est possible de capter avec VB.Net un évènement issu de SQLServer qui m'indiquerai qu'un enregistrement a eu lieu dans une table.
Merci

Thierry

Si tu as peur de ne pas être synchro....

Fais un timer qui se déclenche toutes les 30 secondes....

Citation:

---

Envoyé par thibab

Bonsoir,
Je programme en VB.net 2010 et je voudrais pouvoir lancer une procédure à un moment très précis.
Explication : j'ai un automate connecté à un analyseur de gaz qui renseigne toutes les 2 minutes une base de données sous SQLServer 2000. Je veux récupérer en continu le dernier enregistrement de la base de données dès qu'il est disponible. Si j'utilise un Timer dans VB.Net, je crains de ne plus etre synchro au bout d'un moment. Je voudrais savoir s'il est possible de capter avec VB.Net un évènement issu de SQLServer qui m'indiquerai qu'un enregistrement a eu lieu dans une table.
Merci

Thierry

---

Tu as plusieurs méthodes pour faire cela (enfin, au moins deux) :

En se basant unqiuement sur la base :

- Utiliser un trigger SQLCLR sur ta table qui appelle un webservice qui recevra les notifications d'arrivéede données. Je ne te conseille pas cette méthode car :
- en cas de plante non maitrisée du trigger, tu perdras la transaction d'écriture.
- on doit exécuter le trigger SQLCLR en mode "external access" ce qui peut faire criser certains DBA.
- il faut avoir en plus un système de notification découplé webservice -> client.

Bref beaucoup de complications pour pas grand chose.

Une autre solution bien plus robuste et simple :

- Utiliser un trigger SQL sur la table qui enverra un message dans une SSSB Queue que tu consomme au niveau de ton appli client (ceci à l'avantage de découpler le mécanisme de signalisaton du mécanisme de réception).

Hors base, le plus simple est peut être une troisième solution :

- Implémenter au niveau de ton automate de réception un mécanisme notifiant ton client de l'arrivée de nouvelles données.

Pour ma part, je choisirais sans hésiter l'utilisation de la Queue SSSB. (simple et rapide à programmer, robuste, et découplé).

Citation:

---

Envoyé par mactwist69

Si tu as peur de ne pas être synchro....

Fais un timer qui se déclenche toutes les 30 secondes....

---

C'est un peu bricolo, non ?

Je pense pas, Tu peux avoir un service qui scrute une table, voir plusieurs table.

Si rien a faire, il slepp et puis voila.

C'est sur c'est moins jolie que SSSB ou autres....

Mais en même temps, quel que soit la solution, ton service fonctionne en permanence... Alors que se soit un système complexe qui préviens ton appli ou ton appli qui scrute et dort le reste du temps....

Pour ce cas précis je vois pas l'avantage... (Surtout qu'il doit se mettre à jour toute les 2 min... c'est pas 2 fois par mois) après pour d'autre situation plus complexe ou technique, je suis sur que les autres solutions correspondent plus aux besoins...

Citation:

---

(ceci à l'avantage de découpler le mécanisme de signalisaton du mécanisme de réception).

---

Je vois pas l'avantage ici de découpler.

Parce qu'on découple la programmation, la maintenance, les erreurs possibles également. Pour un truc pas compliqué à la base.

Éclaire ma petite lanterne.

Citation:

---

Envoyé par mactwist69

Je vois pas l'avantage ici de découpler.

Parce qu'on découple la programmation, la maintenance, les erreurs possibles également. Pour un truc pas compliqué à la base.

Éclaire ma petite lanterne.

---

Tout simplement, ne pas avoir à faire d'hypothèses sur la disponibilité du fournisseur vs le consommateur.

Avec une queue, les event sont ... queued et même basculables au cas où ta base passe sur un mirroir.

Donc, que ton consommateur soit dispo ou pas, n'a pas d'influence sur l'intégrité de la chaine applicative : quand il devient dispo, il consomme ses entrées de queue dont il est assuré de récupérer la totalité même en temps différé.

En environnement de production c'est très rassurant.

Citation:

---

Envoyé par mactwist69

Je pense pas, Tu peux avoir un service qui scrute une table, voir plusieurs table.

Si rien a faire, il slepp et puis voila.

C'est sur c'est moins jolie que SSSB ou autres....

---

Le problème n'est pas l'élégance du système, mais la queue a l'avantage de gérer très simplement la disponibilité du système.

cf. ma réponse sur le découplage.

Dès l'nstant où j'ai une chaine applicative qui doit utiliser deux entités logicielle, je dois avoir un mécanisme permettant la reprise si une des deux n'est pas disponible.

+1 pour le système de queue, pour la non perte de données et la disponibilité du système,voir aussi pour un système multiclient ou multi-source... Merci pour la théorie.

Qu'est ce qu'une SSSB Queue ? j'ai beau chercher sur le net, je trouve pas.

Si c'est un élément de l'application cliente, ok, alors il pourrait y avoir un évènement lorsqu'il se remplis, mais si c'est externe... On tourne en rond, car il faudra scruté la queue toutes les x temps....

Excuse moi si je parait insistant, mais c'est vraiment une envie de progresser de ma part.

Citation:

---

Envoyé par mactwist69

+
Qu'est ce qu'une SSSB Queue ?

---

Désolé pour l'abbréviation :D

SSSB = Sql Server Service Broker.

Quelques info là : http://msdn.microsoft.com/fr-fr/library/bb522893.aspx

Par contre,en répondant, je m'apperçois qu'il m'avait échappé que l'initiateur du poste utilisait Sql Server 2000, et là ca pose un problème ...

Merci pour vos réponses, mais je m'aperçois qu'il n'existe pas vraiment de solution simple à mon problème. :cry:
De plus, la seule solution qui semble propre et fiable est celle de l'utilisation du trigger SQL via une SSSB queue. Malheureusement cette solution ne semble pas fonctionner sous SQl Server 2000 si je lis le dernier message de Bluedeep ; pour information, à partir de quel version de SQL Server cette solution de SSB Queue fonctionne ?
Si je ne trouve pas de solution, je serais obligé d'utiliser l'option du Timer qui interroge SQL Server toutes les x secondes.
Encore merci à tous.

Thierry

Citation:

---

Envoyé par thibab

pour information, à partir de quel version de SQL Server cette solution de SSB Queue fonctionne ?

---

Le Sql Server Service Broker (dont les Queue ne sont qu'un des éléments) est disponible à partir de Sql Server 2005. (et enrichi sur le plan fonctionnel avec Sql Server 2008, mais il marche très bien en 2005 : j'ai des projets avec Sql Server 2005 qui tournent en prod et qui s'appuient sur ce mécanisme pour injecter des messages dans Biztalk Server, sans poser le moindre soucis)

Un article sur le blog de SqlPro (qui est grand boula matari de Sql Server sur DVP :D ) à ce sujet :

http://blog.developpez.com/sqlpro/p7...ervice-broker/