Il primo di una serie di articoli su trucchi, consigli, suggerimenti e best practices per scrivere e gestire in modo efficiente i Trigger DML in SQL Server:
SQL Server DML Triggers - Tips & Tricks - Part 1 (Intro & Triggers activation order)
Buona lettura!
Il secondo di una serie di articoli su trucchi, consigli, suggerimenti e best practices per scrivere e gestire in modo efficiente i Trigger DML in SQL Server:
SQL Server DML Triggers - Tips & Tricks - Part 2 (Thought to work on multiple rows)
Buona lettura!
I Trigger sono spesso motivo di discordia tra sviluppatori e DBA, tra chi personalizza un’applicazione standard e chi la produce. Sono spesso i primi imputati quando le performance del database degradano. Sembrano facili da scrivere, ma scrivere Trigger efficienti non è affatto semplice e quando la complessità aumenta, possono presentare effetti collaterali in grado di confondere persino l’autore. Tuttavia, per quanti effetti collaterali possano avere, hanno un pregio dannatamente importante: permettono di risolvere problemi che non potrebbero essere gestiti in qualsiasi altro layer applicativo.
Recentemente ho avuto l’occasione di apprezzare la clausola OUTPUT per determinare il valore degli identificativi univoci (ID) per una colonna con proprietà IDENTITY, per le righe aggiunte a una tabella durante un’operazione di INSERT.
Come indicato sui books online, la clausola OUTPUT, implementata con SQL Server 2005:
“Restituisce le informazioni da (o le espressioni basate su) ogni riga interessata da un’istruzione INSERT, UPDATE, DELETE o MERGE. Questi risultati possono essere restituiti all’applicazione di elaborazione per l’utilizzo nei messaggi di errore, l’archiviazione e altri scopi simili dell’applicazione. I risultati possono anche essere inseriti in una tabella o in una variabile tabella. Inoltre, è possibile acquisire i risultati di una clausola OUTPUT in un’istruzione nidificata INSERT, UPDATE, DELETE o MERGE e inserire tali risultati in una vista o tabella di destinazione”.
Come posso estrarre la lista dei trigger disabilitati per una o più tabelle, o per l’intero database?
Recentemente, ho avuto la necessità di disabilitare temporaneamente (per alcune ore) tutti i trigger definiti su una tabella. La successiva abilitazione, però, doveva tenere conto dei trigger già disabilitati all’origine, che avevo necessità di conoscere prima di eseguire il comando:
ALTER TABLE <nome_tabella> DISABLE TRIGGER ALL;
…in caso contrario, avrei rischiato di abilitare un trigger che in origine era disabilitato!