Version imprimable
Bonjour,
Je dispose d'un service que je souhaiterai exécuter à chaque fois que j'insère un enregistrement dans une base de données... Est-ce que cela est possible ?
Si oui auriez vous un lien vers un doc me permettant d'apprendre à le faire car jusqu'à présent je n'ai trouvé que de la gestion d'évènement avec des interfaces liées à l'application...
Merci de votre aide !
Si je comprends bien tu as un service windows, et tu souhaiterais que lorsque une ligne s'insère en base, ce dernier exécute un traitement ?
oui exactement...
l'idée est que mon service est un "relais" entre ma base de données et un système externe. Lorsqu'un enregistrement est inséré dans la base (la table et les champs sont identifiés et ne changeront pas), le service doit détecter cette insertion pour le transmettre au service extérieur...
Ton moteur de bdd ? sql server ? version ?
euh... ba écoute, à part en demandant à ta base de données de transmettre un évenement à ton service... mais là je vois assez mal comment tu pourrais faire
il y a une solution...
faire en sorte que ton service windows interroge régulièrement (à intervalles régulier) la base de données, et vérifie s'il n'y a pas eu un changement quelconque, pour cela voici quelques voies...
- consulter les logs de la DB afin de pouvoir tracé les derniers évenements qui ont eu lieu et ce qu'ils ont fait (pas forcément aisé à mettre en oeuvre et totalement lié à un type de SGBDR) => plus sure et fiable et surtout pas de mapping ni rien ne mémoire.
- faire un mapping par Entity Framework et le laisser se démerder en faisant faire un update de ses données régulièrement par la base, si un changement à eu lieu... t'a plus qu'a agir...
d'autres voies existes mais là pour l'instant... si quelqu'un a une autre idée
Je m'explique,
si tu travailles en SQL Server 2005 ou ult, as tu pensé aux assemblies injectés (oui oui, on peut écrire du code .net, utilisé dans Sql server),
et là peut être qu'il y a une solution !
Sinon, le seul moyen que je vois, est de flagguer ta table avec un timestamp (ou une datetime),et ton service window scrute à intervalle régulier (paramétrable) les enregistrements modifié, en notant le dernier timestamp lu (histoire de lire que les enregistrements différentiels).
Car à ma connaissance, on ne peut pas lier (sous forme évènementielle) un service windows à une instance sql server...
ou alors ya la solution des EAI mais couteuse...
Exemple d'assembly injecté avec trigger sur table
http://iroshan29.blogspot.com/2009/0...rver-2005.html
EDIT : autre exemple http://www.15seconds.com/Issue/041006.htm
Lorsque je dis ca, j'entends bien sur ajouter un champ de type timestamp, ou datetime avec comme une valeur par défaut insérée par le moteur de bdd lors de l'insertion d'un enregistrementCitation:
sinon, le seul moyen que je vois, est de flagguer ta table avec un timestamp
(petite précision)
Exemple champ Datetime => getdate() en valeur par défaut dans la bdd
Merci de ta réponse... Je vais étudier la solution du trigger... En revanche en surfouillant sur le web, j'ai trouvé cette solution : passer par un DataSet pour stocker les données et y coller un SqlRowUpdatingEventHandler... Ca me parait aussi assez puissant dans la mesure où je n'ai pas à interroger régulièrement ma base (et donc générer du trafic et de la charge pour rien) :
http://www.java2s.com/Code/CSharp/Da...datedevent.htm
qu'en penses-tu ?
J'aime pas les dataset...
ca bouffe beaucoup de ram, ca génère du trafic inutile, il risque de monter tous les enregistrement en mémoire, etc, et prime on a pas la main pour le gérer (ou si peu)
Un jour, j'ai été consulté pour un projet dans lequel les developpeurs avaient utilisé un dataset...
et pour 10 enregistrements ca marchait mais pour un certain nombre (que j'ai oublié) ca plantait grave l'appli (fallait plus de 5min pour démarrer l'appli, la quantité de ram utilisée était monumentesque) etc.
je dis ca ... je dis rien... :)
Dans le lien que tu donnes, il fait un
ca remplit la datatable x du dataset avec tous le contenu de la table :cry:Code:da.Fill(...
avec le contenu de la requête si je ne m'abuse !Citation:
ca remplit la datatable x du dataset avec tous le contenu de la table
bon en revanche si c'est pas optimisé pour la gestion mémoire, je vais réfléchir sur la solution trigger ou interrogation régulière de la DB.
La solution combinée sera peut être de faire un dataset qui ne mange qu'un seul flag... au changement du flag, j'exécute mon appli (et je me démerde pour trouver les enregistrements qui ont changé)
Oui... c'est sur ;) en fonction de la requête...
mais je persiste et signe: j'aime pas les sqldataadapter, et dataset ...
ils comportent des risques...
Je préfère alors une interrogation régulière de base !
Tiens, j'ai l'impression que tu as écarté les injection d'assembly dans sql server ... pour ma culture perso, tu pourrais me dire pq (humble curiosité)
ok, j'ai bien compris ton aversion pour les datasets, mais il me semble qu'un dataset, non pas de données mais de flag qui permettent de simuler des "event" sans manger trop de ressources, non ? ;-)
concernant les assemblys, je ne l'ai pas volontairement écarté, mais le peux qui j'y ai touché concernait le déploiement de SSIS et... madre des dios quelle horreur à déployer ! Donc j'étudierai peut être cette solution mais avec un à priori certain du fait de mon expérience !
Oui, faut voir, évidemment, disons que je me méfie de cet objet "obscure"... et que je préfère (aujourd'hui) mettre en place quelque chose qui dispose d'un peu plus de code, afin de mieux maitriser les effets de bord... même pour de petites choses.
Car qui sait l'évolution d'un soft... aujourd'hui ca peut correspondre à la quantité de données, champs, etc, mais demain ...
et en prime peut être que demain, ce ne sera pas toi qui en fera la maintenance (mais cela tu le sais ;) )
bref...
A mes yeux : c'est un objet "du côté obscur de la force" qui peut mal réagir...
et l'expérience...
comme les assemblies... meunon, je déconne... :lol:
lol
:ccool:
Si tu as besoin n'hésite pas !
Merci !!! :P:P:P