Notifier les changements d'une base de données SQL Server à son application .Net

Bonsoir,

Je vous présente un nouveau tutoriel : Comment notifier les changements d'une base de données SQL Server à son application .Net par Loick DESTIN de Soat.

SQL Server est un système de gestion de base de données « Made In Microsoft » très complet qui offre l'accès à plusieurs services. Ceux qui vont nous intéresser ici, sont ceux qui vont permettre à notre base de données de notifier nos applications de ses changements.

En effet, grâce à certains services dont on va parler dans cet article, il est possible d'envoyer des messages à nos applications, mais aussi de créer des requêtes de notification, on y reviendra plus tard. Commençons par le « Service Broker ».


:fleche: Retrouvez tous les meilleurs cours et tutoriels pour apprendre Microsoft SQL Server

J'ai essayé la technique décrite dans cet article (notifications SQL Server) il y a pas mal d'années (fin 2006) sous SQL Server 2005.

L'environnement en question nous a permis de voir comment l'outil se comporte sous la charge (données qui changent très souvent, nombre d'applications clientes qui est rapidement passé de 2 à une petite dizaine...).

---

Nous avons été confrontés à un certains nombre de problèmes :

- une fois que l'événement OnChange est levé, il est nécessaire de se réabonner. Le problème, c'est que si l'abonnement échoue pour une raison ou une autre (ex.: base surchargée) et qu'on ne le détecte pas correctement, alors on perd toute notification, plus rien n'est mis à jour et on ne s'en rend pas forcément compte tout de suite

- plus embêtant : dans certains cas (je n'ai pas pu vérifier mais je pense que ça arrive quand on perd la communication client-serveur ou quand le client crash, et donc on n'a pas pu appeler à la méthode SqlDependency.Stop() correctement), on se retrouve avec des transactions en suspens, ce qui n'est pas bon du tout. Ça a posé tout un tas de problèmes au niveau de la maintenance de la base (backups qui échouent, fichiers de log transactionnels extrêmement volumineux...)


Vu les problèmes recontrés, nous avons préféré faire machine arrière et trouver d'autres solutions (même un simple pooling de base, ça posait moins de problèmes !)

---

J'avais bien pensé à écrire un article dessus à l'époque (vers 2007), mais j'ai préféré m'abstenir.

À mon sens, cet outil n'est pas à mettre entre toutes les mains :

- il est très facile de se retrouver avec des cas à problèmes (mécanisme de notification qui s'arrête subitement, transactions qui restent en suspens suite à un dysfonctionnement logiciel...)

- si on est capable d'implémenter les notifications correctement, alors on est tout aussi capable de trouver d'autres solutions beaucoup plus sures (ex: notifications gérées au niveau du logiciel et non pas par la base elle-même)


Ce qu'il faut retenir : il ne faut pas multiplier les notifications SQL à outrance, car au-delà d'une certaine charge ça devient vite dangereux. Votre DBA vous dira merci.

Assez daccord avec Pierre, j'ai personnellement ré implémenté pour mes développeurs un système de notification perso inspiré de SQlCacheDependency...

Très bon tutoriel