Evenement Insert,Update,Delete sur une table

Bonjour

Je travalle en .NET cSharp et j'aimerais recevoir un évennement si certaines tables sont Modifiées (MSSS 2008)

J'essaye de googeller un peu mais ce que je trouve ne me donne pas encore une idée tres claire de la chose

Entre autre
Niveau DB

Niveau C#

- Est il possible de limiter les event a certaines tables seulement ?
- Pourquoi dans l'exemple C# on associe une commande Select a la Classe SqlDepedency qui devrait notifier un Insert ou un update ?

Bref je ne parviens pas encore a me faire une idée claire pour aborder la chose

J'ai aussi trouvé ceci qui semble faire une synthese des deux autres post
Synthese

Je vais continuer à lire et relire, mais si quelqu'un a quelques suggestions ou explications sur le sujet, elles sont bienvenue !

Merci de votre aide

Bonjour,

Cela dépend surtout de ce que vous souhaitez consommer au niveau applicatif : si vous avez simplement besoin de savoir qu'une table a été touchée par une instruction DML, ou si vous avez besoin des données qui été modifiées. Peut-être aussi que seule la dernière modification pour une valeur de clé unique particulière est intéressante, ou que vous avez besoin de la liste de toutes les modifications ... ;)

@++ ;)

Bonjour Elsuket

Dans ce cas ci et dans la majorité des cas le simple fait de savoir qu'un record a été inséré, modifié ou effacé suffit !
Meme pas besoin de savoir lequel

Il s'agit pour une application de charger des tables de travail relativement stables (pas de modification quotidienne)
Mais d'etre le cas échéant prevenu qu'un reload est nécessaire
Le cas échéant un reload complet est prévu

Dans ce cas les notifications d'événement pourraient convenir, mais cette fonctionnalité est dépréciée et plutôt lourde à coder et à maintenir.

Le déclencheur DML aurait convenu, mais il va ralentir l'exécution du chargement de données, surtout s'il est volumineux.

Ne vous est-il pas possible de faire faire ce type de travail à l'application qui charge les données ? Par exemple, on lui ferait écrire que les tables ont été chargées avec succès dans une petite table utilitaire, et les interfaces client vérifient régulièrement le contenu de cette table.

@++ ;)

Citation:

---

Envoyé par Elsuket

Par exemple, on lui ferait écrire que les tables ont été chargées avec succès dans une petite table utilitaire, et les interfaces client vérifient régulièrement le contenu de cette table

---

Tout a fait !
Merci Elsuket c'est la premiere idée que j'avais eue mais comme j'avais vu que SQL Server permettait de gerer les Event j'ai voulu investiguer cela

Mais tu confirme mon sentiment que ca semble d'une part asser lourd a mettre en oeuvre et sans doute asser gourmand en ressources aussi

Comme l'application d'administration des données passe par des classe d'acces dédié je peux facilement intervenir a ce niveau pour updater une petite table sémaphore
Ou mieux encore, je peux ecrire un trigger qui ecrira dans cette table sémaphore

Bonjour,

En l’occurrence, le service broker, qui est asynchrone, pourrait aussi être une solution a explorer...

Citation:

---

Envoyé par olibara

Comme l'application d'administration des données passe par des classe d'acces dédié je peux facilement intervenir a ce niveau pour updater une petite table sémaphore
Ou mieux encore, je peux ecrire un trigger qui ecrira dans cette table sémaphore

---

Oui. En revanche comme je le disais, gare au trigger qui peut augmenter la durée des transactions de chargement de données ;)

Citation:

---

Envoyé par aieeeuuuuu

En l’occurrence, le service broker, qui est asynchrone, pourrait aussi être une solution a explorer...

---

Tout à fait, d'ailleurs les notifications d'événement reposent sur Service Broker. Mais comme je le disais, cela me semble relativement lourd simplement pour "détecter" qu'une table a été chargée. Qu'en penses-tu ?

@++ ;)

Citation:

---

Envoyé par elsuket

Qu'en penses-tu ?

---

Oh, je n'en pense rien, C'était juste pour faire avancer le schmilblick :zoubi:

Je proposais juste cette alternative parce qu’elle a l'avantage d’être asynchrone.

Mais je pense qu'une table outil telle que tu la décrit peut très bien faire l'affaire. D'autres solutions pourraient être aussi envisagées, mais tout dépend des besoins d'Olibara, du contexte,...

1/ Combien de clients connectés qui vont venir vérifier régulièrement si des nouvelle données sont dispo ?
2/ A quelle fréquence (et donc quelle latence maximale souhaitée dans la mise à jour des données dans l'application) ?
...