TRIGGER HISTORIQUE DES MODIFICATIONS

bonjour,
J'essaie de créer un trigger qui récupère les lignes supprimées ou modifiées du Docligne et les stocker dans une table F_DoclignHist

Code: Tout sélectionner

CREATE TRIGGER Trace_User ON dbo.F_DOCLIGNE
for UPDATE,  DELETE as
DECLARE @User_op varchar(50)
DECLARE @op_type varchar(10)
DECLARE @Date_op smalldatetime
DECLARE @Date_saisieOld smalldatetime
DECLARE @inc int


SELECT @user_op = nt_username, @Date_op = getdate() FROM
master..sysprocesses WHERE spid=@@SPID

 if EXISTS(SELECT * FROM DELETED)
  begin
    delete  from f_doclignhist_tmp
    if exists (select * from inserted)
     begin
      set @op_type='MODIF'
     
      INSERT into f_doclignhist_tmp   (op_type, date_op, user_op, DO_Piece, DO_Date, DL_ligne, AR_ref, DL_design, DL_Qte,DL_Remise01REM_Valeur,DL_PrixUnitaire,DL_No, utilisateur)
      Select  @op_type, @date_op, @user_op, d.DO_Piece, d.DO_Date, d.DL_ligne, d.Ar_Ref, d.DL_design, d.DL_Qte, d.DL_Remise01REM_Valeur, d.DL_PrixUnitaire, d.DL_No, d.utilisateur
      FROM DELETED d


     end
    else
  begin
  set @op_type='SUPPR'


  INSERT into f_doclignhist_tmp  (op_type, date_op, user_op, DO_Piece, DO_Date, DL_ligne, AR_ref, DL_design, DL_Qte,DL_Remise01REM_Valeur,DL_PrixUnitaire,DL_No, utilisateur)
  Select @op_type, @date_op, @user_op, d.DO_Piece, d.DO_Date, d.DL_ligne, d.Ar_Ref, d.DL_design, d.DL_Qte, d.DL_Remise01REM_Valeur, d.DL_PrixUnitaire, d.DL_No, d.utilisateur
  FROM deleted d

end
end
 insert  into f_doclignhist  select * from f_doclignhist_tmp


Le Problème que ça marche bien pour la suppression. Cependant lors de la modification, le trigger ajoute deux lignes, respectivement celles avant et après la modification.
Pourtant, la table temporaire F_doclignhist_tmp contient toujours une et une seule ligne.

quelq'un peut m'aider?

Bonjours votre problème me fait avancer sur un point que j'arrive pas à résoudre ;
lors de la saisie d'un règlement je souhaite savoir l'utilisateur qui a effectuer le règlement , j'ai chercher une piste et je tombe sur cella . j'ai besoin d'une table qui m'indique qui insérer ou modifier un règlement .
svp est ce que vous pouvez m'aider .

Bonjour Mr nizarbraham,
Ilya longtemps que j'ai cherché comment savoir qui a supprimé ou modifié des données sur l gestion commerciale,
j'ai utilisé votre script mais j'ai besoin de votre aide,
f_doclignhist_tmp elle est où cette table ?
comment afficher le résultat qu'on veut ????
Merci d'avance.

Bonjour Loubna,
La table f_doclignhist_tmp est une table utilisateur crée par moi-même,
Elle hérite la même structure que la table f_doclignhist.

Pour l'exploitation des résultats, c'est généralement sur Access où tu peu afficher par utilisateur, par pièce, par article, etc.


Mon problème initial reste statique et sans issue

Bonjour,
Désolé mais j'ai rien comprit, la table f_doclignhist n'existe plus,
j'aimerai bien que vous m'expliquer les démarches pour faire une traçabilité sur les transactions faites par un utilisateur.
Merci beaucoup

Bonjour,
pour le sujet de traçabilité, est ce qu'ilya de nouveau
Merci

Bonjour à tous,

Je suis aussi très intéresse par ce sujet et surtout pour placer "des mouchards" afin de pouvoir détecter les modifications ou suppression sur mes données Sage (facture, règlement, stock...)
Y a pas une nouvelle proposition de prototype pour ça?

Merci d'avance pour votre collaboration

Bonjour,
oui moi aussi j'aimerais bien avoir une autre solution, parceque je n'arrive pas à utiliser la solution déjà proposée !

Bonjour à tous,
Toujours pas de réponse à ce sujet!
Avoir l'historique des modification est devenue un besoin indispensable
Pourrions nous avoir un script fonctionnel pour résoudre ce problème

@nizarbraham: avez vous avancé sur votre script?

Merci d'avance pour votre collaboration
Cordialement

Bonjour,

J'ai peut-être une piste pour vous. Lors d'une formation chez Sage, on nous a donné une procédure pour créer un mouchard, en l’occurrence ici, sur la suppression des fiches tiers (donc à réadapter à vos besoins).

1- Création de la table par requête:

Code: Tout sélectionner

USE [BIJOU]
GO

CREATE TABLE [dbo].[REM_MOUCHARD] (
     [SpId] [smallint] NULL,
     [KpId] [smallint] NULL,
     [Blocked] [smallint] NULL,
     [DbId] [smallint] NULL,
     [UId] [smallint] NULL,
     [HostName] [nvarchar] (50) NULL,
     [Program_Name] [nvarchar] (50) NULL,
     [Nt_Domain] [nvarchar] (50) NULL,
     [Nt_UserName] [nvarchar] (50) NULL,
     [LogiName] [nvarchar] (50) NULL,
     [Table_Name] [nvarchar] (50) NULL,
     [Mou_Date] [nvarchar] (30) NULL,
     [CT_Num] [nvarchar] (17) NULL,
) ON [PRIMARY]

GO

Il est possible de créer cette table directement dans la bd avec Management Studio.

2- Création du trigger:

Code: Tout sélectionner

USE [BIJOU]
GO

CREATE TRIGGER [dbo].[REM_TG_DEL_F_COMPTET] ON [dbo].[F_COMPTET]
FOR DELETE
AS
DECLARE @a varchar(17)
SELECT @a=DELETED.Ct_Num FROM deleted
INSERT INTO [dbo].[REM_MOUCHARD]
SELECT SpId,KpId,Blocked,DbId,UId,HostName,Program_Name,Nt_Domain,Nt_Username,LogiName,'F_COMPTET',getdate(),@a
FROM master..sysprocesses WHERE spid=@@SPID

En espérant que ça pourra aider !

Bonjour à tous,

Merci Funkydiem pour cette proposition mais j'aimerai savoir s'il existe quelques chose similaire à ce Triggers pour le suivi des modifications de Documents (achat,vente ou stock)

Cordialement

Bonjour à tous,

J'ai réussi à bricoler un trigger sur ma table DOCLIGNE mais j'ai un problème avec la transformation des documents.
Quand je transforme par exemple un BC en BL, mon trigger supprime toutes les lignes d'articles et puis insert à nouveau ces mêmes articles(avec un DO_Type et DO_Piece différent)!Ceci n'est pas très conviviale comme fichier log!!

Avez vous une idée comment contourner ce problème?

Merci d'avance pour votre aide.

Bonjour,

Tu n'as pas beaucoup d'autres solutions ... On ne peut pas modifier le DO_PIECE et le DO_TYPE. Les triggers de SAGE bloquent.

Tu dois donc supprimer ta ligne (après l'avoir enregistré quelque part ..) et en créer une nouvelle.

Sinon, il faut désactiver les triggers internes de SAGE, modifier tes lignes et déactiver les triggers de SAGE ... Pas conseillé du tout
Cdlt

Bonsoir à tous,

Merci pour vos réponse mais j'ai deux autres questions sur les Triggers:

1. J'ai crée un Trigger Insert/Delete et Update sur F_COMPTET, mais le problème qu'à chaque nouvelle création de client et quand je passé d'un onglet à un autre pour renseigner tous les champs, j'aurai automatiquement le déclenchement du Trigger insert et au même temps update (vue qu'il suffit de valider le premier onglet de la fiche client, les autres infos les considère comme action d'update)

Avez vous une idée pour contourner ce problème?

2. Je souhaite faire sur mon trigger F_COMTET faire une jointure avec F_REGLEMENTT afin d'avoir les modalité de paiement.(mode de paiement, nbre de jours....)
Comment faire cette jointure?

Merci d'avance

Cordialement

DaliPieo a écrit:... 1. J'ai crée un Trigger Insert/Delete et Update sur F_COMPTET, mais le problème qu'à chaque nouvelle création de client et quand je passé d'un onglet à un autre pour renseigner tous les champs, j'aurai automatiquement le déclenchement du Trigger insert et au même temps update (vue qu'il suffit de valider le premier onglet de la fiche client, les autres infos les considère comme action d'update)
Avez vous une idée pour contourner ce problème? ...

Je ne pense pas qu'il faille contourner ce problème (dans tous les cas, cela ne me semble pas possible sans refaire un petit Sage à la place de Sage).
Par contre rien ne t'empêche dans ton trigger ou dans ton logiciel d'analyse des traces de prendre en compte ce comportement pour ne présenter à l'utilisateur qu'une ligne de trace.
Je ne dis pas que ce soit simple, mais c'est la voie que j'ai choisie quand j'ai eu des trucs de ce style à traiter.

DaliPieo a écrit:... 2. Je souhaite faire sur mon trigger F_COMTET faire une jointure avec F_REGLEMENTT afin d'avoir les modalité de paiement.(mode de paiement, nbre de jours....)
Comment faire cette jointure? ...

Le lien est sur le CT_Num, mais ta question doit sans doute être autre.
Si c'est comment faire un lien en TSQL, tu trouveras beaucoup de doc là dessus sur le net car il y a plusieurs possibilités selon ce que tu veux faire.

Bonjour à tous,

Merci pour vos réponse mais j'ai un problème de récupération de l'enregistrement mis à jour c'est à dire
j'ai fait une jointure entre la table F_COMPTET et F_REGLEMENTT comme suit

Code: Tout sélectionner

select @NBJOUR= RT_NBJour from BIJOU..F_REGLEMENTT where F_REGLEMENT.CT_Num=Code_Client

Mais je souhaite récupérer le nombre de jour (NBjour) mis à jour c'est à dire celui inséré et supprimé

Comment pourrais-je le récupérer?

Cordialement

Bonjour,

Merci bcp pour les different pistes.

En plus de l'utilisateur Windows, Est-ce qu'on peut aussi recuperer l'utilisateur SAGE dans le trigger?


Merci.

Bonjour,

Vous trouvez pas que ça devient un peu le bazar ce post ...

Pensez à ceux qui utilisent Rechercher en haut ...

Un post = une question

Merci

Cdlt

Bonjour nizarbraham,

Code: Tout sélectionner

[quote]Le Problème que ça marche bien pour la suppression. Cependant lors de la modification, le trigger ajoute deux lignes, respectivement celles avant et après la modification.
Pourtant, la table temporaire F_doclignhist_tmp contient toujours une et une seule ligne.

quelq'un peut m'aider?
nizarbraham
Posteur néophyte
[/quote]

après le test de code de trigger, le probleme je ponse dus d'un multiple commande de mise à jour déclencher par sage au moment de la modification d'une ligne de document.
j'ai pas pu résoudre le problème, si quelqu'un trouver la solution merci de bien m'aider ?

Bonjour,

Il n'y a pas vraiment de solution puisqu'il s'agit là du comportement intrinsèque de Sage.

Cela est sans doute dû à une façon de concevoir le code lors de l'apparition des informations libres et de leur gestion à travers l'interface du logiciel en version cbase, qui a été transposé "tel quel" lors du passage en version SQL Server.
Il s'avère en effet que tout ajout de ligne (INSERT) ou modification de ligne (UPDATE) dans une table qui contient des informations libres (F_COMPTET/G, F_DOCENTETE, F_DOCLIGNE, etc.) génère deux "transactions" (je mets entre parenthèse car il ne s'agit pas de transaction SQL au sens BEGIN TRAN / COMMIT TRAN strict du terme) SQL : L'insert sur tous les champs "standards" de la table en question, suivi immédiatement par un joli SELECT @cbMarq=cbMarq FROM latableenquestion pour enfin terminer par un UPDATE des champs libres where cbMarq...

C'est immonde du point de vue du design, de l'optimisation, etc. mais c'est comme ça donc il faut vivre avec...

Le mieux que vous puissiez faire est :
1) soit vous filtrez la requête qui renvoie le résultat de cette table de tracking, par un distinct astucieux ou un top 1 par exemple, basé sur la date du jour (sans les heures/min sinon ça ne donnera pas de résultat) mais vous conservez des "doublons" de lignes dans votre table de tracking
2) soit vous limitez au maximum ces doublons (et encore ce n'est possible qu'en update et sur certains champs) en update par exemple en comparant la valeur de chaque champ mis à jour hormis les infos libres des tables inserted et deleted. Cette solution n'est qu'exceptionnelle et ne peut fonctionner que dans des cas très spécifiques, donc au final dans disons 99% des cas la seule chose à faire c'est de se contenter des doublons ou de les élminer dans les rapports d'audit (cf point 1))

Si vous avez déjà manipulé les Objets Métiers, vous connaissiez sans doute déjà ce comportement sans le savoir (d'abord faire un write de l'objet, puis en refaire un pour les infos libres... O_O)

Dans quasiment toutes les tables de SAGE, vous trouverez des triggers qui réalisent des update de l'update précédent...
Cela sert entre autre à remplir les champs cb (il y a un update par champ cb)

Code: Tout sélectionner

ALTER TRIGGER [dbo].[TG_CBUPD_F_DOCLIGNE] ON [dbo].[F_DOCLIGNE] FOR UPDATE AS
...
IF UPDATE(CO_No)
         UPDATE F_DOCLIGNE SET cbCO_No = NULLIF(inserted.CO_No,0) FROM inserted WHERE F_DOCLIGNE.cbMarq = inserted.cbMarq;
      IF UPDATE(DT_No)
         UPDATE F_DOCLIGNE SET cbDT_No = NULLIF(inserted.DT_No,0) FROM inserted WHERE F_DOCLIGNE.cbMarq = inserted.cbMarq;
      IF UPDATE(DE_No)
         UPDATE F_DOCLIGNE SET cbDE_No = NULLIF(inserted.DE_No,0) FROM inserted WHERE F_DOCLIGNE.cbMarq = inserted.cbMarq;

Cela explique en partie les doublons dans la table de log.

De plus, en effet comme le dit Le_Maraudeur, SAGE fait depuis l'application un nombre considérable d'Update...

Lorsque vous déclenchez une erreur SQL depuis SAGE, vous avez 2 fois le message "ERREUR SQL" avant le vrai message d'erreur, c'est sans doute la même cause.

Voici ce que j'ai fais :

************* Début *****************

Step 1 : Création de la table des logs.

CREATE TABLE [dbo].[F_LOGCIAL] (
[SpId] [smallint] NULL ,
[KpId] [smallint] NULL ,
[Blocked] [smallint] NULL ,
[DbId] [smallint] NULL ,
[UId] [smallint] NULL ,
[HostName] [nvarchar] (50) NULL ,
[Program_Name] [nvarchar] (50) NULL ,
[Nt_Domain] [nvarchar] (50) NULL ,
[Nt_UserName] [nvarchar] (50) NULL ,
[LogiName] [nvarchar] (50) NULL ,
[Table_Name] [nvarchar] (50) NULL ,
[Mou_Date] [nvarchar] (30) NULL ,
[Ref_Article] [nvarchar] (19) NULL ,
[Qte] [numeric](24, 6) NULL ,
[PU] [numeric](24, 6) NULL ,
[Etat] [varchar] (50) NULL ,
[numPiece] [varchar] (9) NULL ,
[idx] [int] IDENTITY (1, 1) NOT NULL ,
[oldQte] [varchar] (19) NULL ,
[oldUniPrice] [numeric](24, 6) NULL
) ON [PRIMARY]

Step 2 : Création des triggers.

CREATE TRIGGER [dbo].[myTG_DEL_F_DOCLIGNE] ON [dbo].[F_DOCLIGNE]
FOR DELETE
AS
DECLARE @a varchar(19)
DECLARE @b numeric(24,6)
DECLARE @c numeric(24,6)
DECLARE @d varchar(9)
SELECT @a=DELETED.AR_Ref,@b=DELETED.DL_Qte,@c=DELETED.DL_PrixUnitaire,@d=DELETED.DO_Piece FROM deleted
INSERT INTO [dbo].[F_LOGCIAL]
SELECT SpId,KpId,Blocked,DbId,UId,HostName,Program_Name,Nt_Domain,Nt_Username,LogiName,'F_DOCLIGNE',getdate(),@a,@b,@c,'SUP',@d,0,0
FROM master..sysprocesses WHERE spid=@@SPID



CREATE TRIGGER [dbo].[myTG_INS_F_DOCLIGNE] ON [dbo].[F_DOCLIGNE]
FOR INSERT
AS
DECLARE @a varchar(19)
DECLARE @b numeric(24,6)
DECLARE @c numeric(24,6)
DECLARE @d varchar(9)
SELECT @a=INSERTED.AR_Ref,@b=INSERTED.DL_Qte,@c=INSERTED.DL_PrixUnitaire,@d=INSERTED.DO_Piece FROM INSERTED
INSERT INTO [dbo].[F_LOGCIAL]
SELECT SpId,KpId,Blocked,DbId,UId,HostName,Program_Name,Nt_Domain,Nt_Username,LogiName,'F_DOCLIGNE',getdate(),@a,@b,@c,'AJOUT',@d,0,0
FROM master..sysprocesses WHERE spid=@@SPID




CREATE TRIGGER [dbo].[myTG_UPD_F_DOCLIGNE] ON [dbo].[F_DOCLIGNE]
FOR UPDATE
AS
DECLARE @a varchar(19)
DECLARE @b numeric(24,6)
DECLARE @c numeric(24,6)
DECLARE @d varchar(9)
DECLARE @e numeric(24,6)
DECLARE @f numeric(24,6)

SELECT @a=INSERTED.AR_Ref,@b=INSERTED.DL_Qte,@c=INSERTED.DL_PrixUnitaire,@d=INSERTED.DO_Piece,@e=DELETED.DL_Qte,@f=DELETED.DL_PrixUnitaire FROM INSERTED INNER JOIN DELETED ON DELETED.AR_Ref = INSERTED.AR_Ref
IF @b <> @e OR @c <> @f
BEGIN
INSERT INTO [dbo].[F_LOGCIAL]
SELECT TOP 1 SpId,KpId,Blocked,DbId,UId,HostName,Program_Name,Nt_Domain,Nt_Username,LogiName,'F_DOCLIGNE',getdate(),@a,@b,@c,'UPDT',@d,@e,@f
FROM master..sysprocesses WHERE spid=@@SPID
RETURN
END


************ Fin ************

J'ai testé sur SAGE SQL Version 14 & Version 16 ça marche sans problèmes.
ce ci est une modeste participation et bien sûr il se peut que j'ai raté quelque chose.

Bonjour,

Là, tu trace les modifs sur ligne de doc., OK (et encore, ça doit pas mal plomber le temps d'insert/update dans la base et je ne suis pas sûr du résultat en cas de transformation de pièces en masse : je prends 10 commandes et demande leur transformation en BL ...).

Mais moi, je veux tout tracer ....

Autant stocker les logs SQL et se faire les outils (ou en trouver sur le net) pour les relire ....

Cordialement,