Ecco l'inizio di un tipico Trigger di SQL Server 2000:
CREATE TRIGGER Trigger_Name ON Table_Name AFTER UPDATE
AS BEGIN
IF @@ROWCOUNT=0 --no record effected, so nothing to do
RETURN
...
Ma perchè controllare che sia partito realmente un aggiornamento in questa tabella? Cito l'eloquente spiegazione di Kalen Delaney contenuta nel suo Inside MsSQL Server 2000 (PartIII - Chapter 12):
"a trigger fires even if no rows were affected by the update. Recall that the plan for the trigger is appended to the rest of the statements' execution plan. You don't know the number of rows affected until execution. This is a feature, not a bug; it allows you to take action when you expect some rows to be affected but none are. Having no rows affected is not an error in this case. However, you can use a trigger to return an error when this occurs"
Sempre relativamente al funzionamento dei trigger, da non sottovalutare è questa considerazione fatta nello stesso capitolo, a proposito dell'impiego di cursori in un trigger per la gestione di aggiornamenti multipli di Chiavi Primarie:
"You might think that you can write a trigger to handle multiple updates to the primary key by using two cursors to step through the inserted and deleted tables at the same time. However, this won't work. There's no guarantee that the first row in the deleted table will correspond to the first row in the inserted table, so you cannot determine which old foreign key values in the referencing tables should be updated to which new values."
Non è la prima volta, e non sarà l'ultima, che un collega mi chiede se "conviene" fare caricare un recordset di ADO con una SELECT * oppure SELECT field1, field2. Anch'io sono stato un programmatore VB (..in verità lo sono ancora anche se spero di non esserlo più!) e so bene cosa vuol dire ragionare da VBDeveloper: "so di non sapere bene quello che faccio fare al mio linguaggio e preferisco fare meno cose nel più breve tempo possibile". Quindi sulla stregua di questo modo di pensare, il programmatore pensa che convenga non precisare i singoli campi per il solo fatto che, se ne dovesse aggiungere un'altro nella tabella selzionata, non dovrà preoccuparsi di modificare il codice (..sì, perchè dove pensi che abbia inserito la query?).
Premesso che una VIEW potrebbe venire incontro all'ozio del nostro programmatore (anche se opportunamente "rinfrescata" col comando SP_REFRESHVIEW), c'è da considerare che quell'asterisco condiziona il traffico di rete dal server vs il client (soprattutto se il peso di un record della nostra tabella o join di tabelle supera i 4KB, ovvero occupa l'intera pagina con cui lavora SQLServer che è 8KB). Inoltre, usando l'asterisco ci precludiamo la possibilità di sfruttare i cosiddetti covered index, ovvero gli indici che coprono l'intera Select (meglio ancora se clustered index) e che garantiscono prestazioni di gran lunga migliori.
Nuovi incentivi del governo all'E-Commerce: con una spesa minima di € 30.000 concedono crediti d'imposta pari al 50%. Tempo restante per l'offertissima: 90 giorni dalla data di pubblicazione sulla Gazzetta Ufficiale.
La circolare è qui in .pdf, ed è in fase di pubblicazione.