none
Trigger anomalo su update Tabella RRS feed

  • Domanda

  • Ciao, il trigger accoda i record anche se i record della tabella DESTINAZIONIDIVERSE non sono modificati... come può essere?...




    ALTER TRIGGER [dbo].[BIRI_TU_DESTINAZIONIDIVERSE] ON [dbo].[DESTINAZIONIDIVERSE] FOR UPDATE AS
    BEGIN
        DECLARE
           @NUMROWS  INT,
           @ERRNO    INT,
           @ERRMSG   VARCHAR(255),
       @CONN VARCHAR(255)
    --    @ProcName VARCHAR(255)

        SELECT  @NUMROWS = @@ROWCOUNT
        

        IF @NUMROWS = 0
           RETURN
        SELECT @CONN =  CONCAT(APP_NAME(), ' -- ', SESSION_USER,  ' -- ',system_USER, ' -- ', CONVERT(VARCHAR(255),CONNECTIONPROPERTY ('client_net_address')))
    --client_net_address
    -- SET @ProcName = OBJECT_NAME(@@PROCID) + @CONN;
        



       insert into [BIRI_DESTINAZIONIDIVERSE_UPDATE] (CurrentUser, CODCONTO, CODICE, RAGIONESOCIALE, INDIRIZZO, CAP, LOCALITA, PROVINCIA, TELEFONO, FAX, CODDEPOSITO, CODDEPOSITOCOLL, CODDEPCOMP, CODDEPCOMPCOLL, INOLTROTRASP, UTENTEMODIFICA,
                             DATAMODIFICA, ZonaSped, CodSettoreGiriVisite, email, IdAmmnistratore, codRelazione, CentroCompentenza, codIstatComune, CODNAZIONE, CODDEST_EDI, codiceSapDest, StatoExportDDVSap, Dismesso, NoExport,
                             CodiceComplesso, RSPPdiRif_D, MedicodiRif_D)
       select  @CONN, CODCONTO, CODICE, RAGIONESOCIALE, INDIRIZZO, CAP, LOCALITA, PROVINCIA, TELEFONO, FAX, CODDEPOSITO, CODDEPOSITOCOLL, CODDEPCOMP, CODDEPCOMPCOLL, INOLTROTRASP, UTENTEMODIFICA,
                             DATAMODIFICA, ZonaSped, CodSettoreGiriVisite, email, IdAmmnistratore, codRelazione, CentroCompentenza, codIstatComune, CODNAZIONE, CODDEST_EDI, codiceSapDest, StatoExportDDVSap, Dismesso, NoExport,
                             CodiceComplesso, RSPPdiRif_D, MedicodiRif_D

        FROM   inserted T1

    insert into [BIRI_DESTINAZIONIDIVERSE_UPDATE] (CurrentUser, CODCONTO, CODICE, RAGIONESOCIALE, INDIRIZZO, CAP, LOCALITA, PROVINCIA, TELEFONO, FAX, CODDEPOSITO, CODDEPOSITOCOLL, CODDEPCOMP, CODDEPCOMPCOLL, INOLTROTRASP, UTENTEMODIFICA,
                             DATAMODIFICA, ZonaSped, CodSettoreGiriVisite, email, IdAmmnistratore, codRelazione, CentroCompentenza, codIstatComune, CODNAZIONE, CODDEST_EDI, codiceSapDest, StatoExportDDVSap, Dismesso, NoExport,
                             CodiceComplesso, RSPPdiRif_D, MedicodiRif_D)
       select  @CONN, CODCONTO, CODICE, RAGIONESOCIALE, INDIRIZZO, CAP, LOCALITA, PROVINCIA, TELEFONO, FAX, CODDEPOSITO, CODDEPOSITOCOLL, CODDEPCOMP, CODDEPCOMPCOLL, INOLTROTRASP, UTENTEMODIFICA,
                             DATAMODIFICA, ZonaSped, CodSettoreGiriVisite, email, IdAmmnistratore, codRelazione, CentroCompentenza, codIstatComune, CODNAZIONE, CODDEST_EDI, codiceSapDest, StatoExportDDVSap, Dismesso, NoExport,
                             CodiceComplesso, RSPPdiRif_D, MedicodiRif_D

        FROM   deleted D1





        RETURN

    /*  ERRORS HANDLING  */
    ERROR:
        RAISERROR (@ERRMSG, 1, 1)
        ROLLBACK  TRANSACTION
    END




    Marco

    giovedì 11 aprile 2019 08:40

Risposte

Tutte le risposte

  • ti manca il vincolo sul record che viene aggiornato

    FROM   inserted T1, DESTINAZIONIDIVERSE DD
    where T1.id=DD.id


    Edoardo Benussi
    Microsoft MVP - Cloud and Datacenter Management
    e[dot]benussi[at]outlook[dot]it

    lunedì 15 aprile 2019 10:52
    Moderatore
  • Mi potresti accennare al perchè? è necessario inserire questo vincolo?, e perchè mi restituisce errore se lo inserisco come sotto?... Credo di non afferrare il concetto... mi pare di capire che devo inserire la condizione where in modo che l'id di riga sia lo stesso sia sulla tabella inserted che deleted... corretto?

        FROM   inserted T1 where T1.id = D1.id


    Marco

    lunedì 15 aprile 2019 15:18
  • perchè devi identificare la riga su cui deve intervenire il trigger

    dovresti comunque precisare se nella tabella DESTINAZIONIDIVERSE o nella tabella BIRI_DESTINAZIONIDIVERSE_UPDATE ti trovi righe ripetute e se hai una chiave primaria in entrambe le tabelle


    Edoardo Benussi
    Microsoft MVP - Cloud and Datacenter Management
    e[dot]benussi[at]outlook[dot]it

    lunedì 15 aprile 2019 15:58
    Moderatore
  • La tabella dove trovo le righe ripetute è BIRI_DESTINAZIONIDIVERSE_UPDATE ed in entrambe c'è una chiave primaria

    Marco

    lunedì 15 aprile 2019 16:44
  • quando fai un aggiornamento su un record della tabella destinazionidiverse quanti record ti vengono aggiunti alla tabella biri_destinazionidiverse_update ?

    hai provato ad aggiungere quanto ti ho suggerito ?


    Edoardo Benussi
    Microsoft MVP - Cloud and Datacenter Management
    e[dot]benussi[at]outlook[dot]it

    martedì 16 aprile 2019 08:22
    Moderatore
  • Ho modificato secondo le tue indicazioni... conto di aver fatto giusto...:

      FROM INSERTED T1 INNER JOIN DELETED D1 ON T1.CODCONTO = D1.CODCONTO AND T1.CODICE = D1.CODICE

    il fatto strano che capita è che la tabella destinazionidiverse NON è modificata.... ora sto monitorando tenendo traccia su profiler.. spero di trovare il motivo...
    Altra cosa strana che è successa, in seguito al riavvio dell'istanza (è capitato un paio di volte tempo addietro) si sono accodati decine di migliaia di record e l'utente che ha eseguito l'operazione era "dbo."... 


    Marco

    martedì 16 aprile 2019 08:54

  • il fatto strano che capita è che la tabella destinazionidiverse NON è modificata.... 

    non ho capito. il trigger intercetta gli aggiornamenti di record nella tabella destinazionidiverse ed esegue un'azione (la insert) sull'altra tabella, non viceversa quindi perchè ti aspetti che la tabella destinazionidiverse sia modificata ?

    Edoardo Benussi
    Microsoft MVP - Cloud and Datacenter Management
    e[dot]benussi[at]outlook[dot]it

    martedì 16 aprile 2019 09:33
    Moderatore
  • Il trigger, in caso di modifiche ai record di DESTINAZIONIDIVERSE , accoda vecchio record e record modificato su BIRI_DESTINAZIONIDIVERSE_UPDATE.

    Questo serve a monitorare modifiche anagrafiche da parte degli utenti. Il problema è che di tanto in tanto, gira qualche routine che "sembra" copi ed incolli tale e quale i record di DESTINAZIONIDIVERSE e di riflesso mi trovo i record su BIRI_DESTINAZIONIDIVERSE_UPDATE senza motivo. Tenere sempre tracciato con il profiler non mi è sembrata una strada percorribile perchè il fatto succede una volta al mese, e dovrei terere la traccia sempre in esecuzione...


    Marco

    martedì 16 aprile 2019 14:58
  • ok, adesso è più chiaro.

    e come fai ad avere la certezza che senza alcuna variazione nei record di destinazionidiverse ci sono dei records in append in bir_destinazionidiverse_update ?

    non riesci ad isolare un caso per fare il debug di ciò che accade ?


    Edoardo Benussi
    Microsoft MVP - Cloud and Datacenter Management
    e[dot]benussi[at]outlook[dot]it

    martedì 16 aprile 2019 15:31
    Moderatore
  • sto cercando di isolare, e ad oggi ho capito quale utente lancia la funzione, il prossimo passo che faccio è avviare la traccia su avviso del collega che lancia la funzione per l'invio delle anagrafiche verso SAP. Forse li ne capisco di più...

    La "certezza" della mancanza di variazioni è giustificata dal fatto che il contenuto di tutti i capi del record di DESTINAZIONIDIVERSE è identico sia prima che dopo la funzione incriminata.

    ad ogni modo devo attendere il prossimo mese per il rilancio della funzione.. Vorrei solo essere pronto..)


    Marco

    martedì 16 aprile 2019 15:47
  • Oggi ho lanciato la funzione... mandato in esecuzione una traccia e riscontrato che il trigger funziona correttamente accodando, ad ogni modifica dei record della tabella DESTINAZIONIDIVERSE, i record nella tabella di appoggio BIRI_DESTINAZIONIDIVERSE_UPDATE.

    Possibile che la traccia standard di Profiler non evidenzi scritture sulla tabella BIRI_DESTINAZIONIDIVERSE_UPDATE che pur trova record inseriti?

    I record vengono inseriti dal trigger in tabella... è normale non risultino dalla traccia profiler?.. c'è modo di capire cosa scrive sulla tabella?..


    Marco

    martedì 7 maggio 2019 16:24
  • Possibile che la traccia standard di Profiler non evidenzi scritture sulla tabella BIRI_DESTINAZIONIDIVERSE_UPDATE che pur trova record inseriti?

    non ho capito...


    Edoardo Benussi
    Microsoft MVP - Cloud and Datacenter Management
    e[dot]benussi[at]outlook[dot]it

    mercoledì 8 maggio 2019 07:55
    Moderatore
  • Possibile che la traccia standard di Profiler non evidenzi scritture sulla tabella BIRI_DESTINAZIONIDIVERSE_UPDATE che pur trova record inseriti?

    non ho capito...


    Edoardo Benussi
    Microsoft MVP - Cloud and Datacenter Management
    e[dot]benussi[at]outlook[dot]it

    Nel senso che: le operazioni che esegue il trigger che accoda i record nella tabella BIRI_DESTINAZIONIDIVERSE_UPDATE non vengono scritte dalla traccia Profiler, dunque non ho nemmeno evidenza delle operazioni che svolge il trigger...

    In pratica; per vedere che legge e riscrive i record nela tabella DESTINAZIONIDIVERSE avvio la tracci astandard di Profiler e faccio eseguire la funzione dall'operatore... 

    ieri sono stati scritti 15000 record e non ho alcuna traccia dell'operazione.. forse devo configurare diversamente la traccia in esecuzione sul Profiler...

    spero di essermi spiegato a sufficenza, diversamente fammi sapere...


    Marco

    mercoledì 8 maggio 2019 09:54
  • quindi, riassumo: il trigger funziona perchè, di fatto, accoda le righe ma le operazioni eseguite dal trigger non vengono tracciate dal profiler. giusto ?

    Edoardo Benussi
    Microsoft MVP - Cloud and Datacenter Management
    e[dot]benussi[at]outlook[dot]it

    lunedì 13 maggio 2019 09:02
    Moderatore
  • Esatto..

    Marco

    martedì 14 maggio 2019 07:50
  • https://stackoverflow.com/questions/159526/how-to-get-sql-profiler-to-monitor-trigger-execution

    Edoardo Benussi
    Microsoft MVP - Cloud and Datacenter Management
    e[dot]benussi[at]outlook[dot]it

    mercoledì 15 maggio 2019 12:47
    Moderatore
  • Perfetto!! funziona; ora anche le operazioni che esegue il trigger vengono registrate dalla traccia , ora attendo il prossimo avvio della procedura per vedere che succede in produzione..

    Grazie Edoardo!


    Marco


    • Modificato Berna75 martedì 28 maggio 2019 12:21 Aggiunta descrizione
    martedì 28 maggio 2019 12:20
  • Caso Chiuso, trovato l'errore nella store procedure che aggiorna i dati, la condizione where non filtrava correttamente le righe da aggiornare ed aggiornava tutta la tabella...

    Grazie infinite!


    Marco

    venerdì 14 giugno 2019 09:09
  • ottimo!

    Edoardo Benussi
    Microsoft MVP - Cloud and Datacenter Management
    e[dot]benussi[at]outlook[dot]it

    venerdì 14 giugno 2019 09:19
    Moderatore