Documentazione
torna al sito web >

Trigger utente (API EULANDA SQL)

I trigger rappresentano un metodo elegante per integrare le proprie funzioni, ma anche per modificare i processi in ERP EULANDA®.

Cosa sono i trigger

I trigger sono una forma speciale di procedure memorizzate. Possono contenere quasi tutti i comandi SQL e vengono richiamati automaticamente dal server SQL durante alcune operazioni del database (inserimento, modifica, cancellazione di record di dati).

La possibilità di visualizzare messaggi di errore nel trigger, che vengono visualizzati per l'utente finale e la possibilità di annullare completamente le operazioni originali del database che ha attivato il trigger (rollback), apre una vasta gamma di possibilità di applicazione.

Alcuni dei possibili compiti per un trigger sono:

  • Controllare la coerenza dei dati modificati. E, se necessario, l'emissione di messaggi di errore e l'annullamento delle modifiche.
  • Mantenimento dei dati dipendenti
  • Cancellazione dei dati non più necessari
  • Totali dei moduli in tabelle sovraordinate. Ad esempio, la modifica degli articoli dell'ordine mantiene automaticamente il prezzo totale nell'intestazione dell'ordine.
  • Registrazione delle modifiche, ad esempio per il monitoraggio di singoli utenti, ecc.
  • ma anche azioni completamente diverse, come ad esempio l'invio automatico di un'e-mail quando si converte un ordine in una bolla di consegna.

I trigger sono assegnati alle singole tabelle. Per ogni attivazione vengono definite le operazioni per le quali deve essere attivata. Queste operazioni sono:

INSERIRE, AGGIORNARE e CANCELLARE

Un singolo trigger può anche monitorare diverse di queste operazioni simultaneamente. Tuttavia, lo stesso trigger non può essere memorizzato per più tabelle, anche se le colonne delle tabelle utilizzate sono le stesse.

EULANDA® definisce già i propri trigger per quasi tutte le tabelle, che mappano la business logic. Tuttavia, Microsoft SQL-Server® ha la piacevole caratteristica di memorizzare un qualsiasi numero di trigger per tabella. Non ci sono limiti per gli sviluppatori in termini di estensibilità a questo proposito.

Per integrare l'utente in EULANDA® senza soluzione di continuità e non causare malfunzionamenti, tuttavia, è necessario considerare alcuni aspetti.

Regole per la creazione di trigger utente

  1. Il nome del trigger deve essere conforme alle convenzioni di denominazione per gli oggetti SQL. Il nome deve iniziare con TR_USER_, seguito dall'ID della tabella corrispondente e dall'ID dell'operazione della tabella di attivazione.
    Per ulteriori informazioni, vedere Convenzioni di denominazione.
  2. Il primo comando del trigger deve essere SET NOCOUNT ON. In caso contrario, l'interfaccia database OLE/DB o ADO non è più in grado di assegnare correttamente le modifiche. Questo può portare a errori imprevedibili in EULANDA®.
  3. Non eseguire comandi di SELEZIONE o STAMPA che restituiscano dati o informazioni a livello di applicazione. Ciò porta anche a malfunzionamenti in EULANDA®. Sono consentiti comandi di SELEZIONE che assegnano valori solo alle variabili locali.
  4. L'operazione vera e propria del database non viene completata fino a quando non sono stati elaborati tutti i trigger. Il codice di attivazione ha quindi una notevole influenza sulle prestazioni del sistema nel suo complesso. Assicurarsi che i comandi che richiedono molto tempo all'interno di un trigger non vengano eseguiti inutilmente spesso. Questo può essere impedito da funzioni come UPDATE(). Il problema sarà discusso più dettagliatamente in seguito.
  5. Se nell'attivazione viene eseguita una ROLLBACK, RAISERROR deve essere attivato con un messaggio di errore significativo e un livello di gravità di 16. Altrimenti EULANDA® presume che non si sia verificato alcun errore.
  6. i trigger devono tener conto del fatto che l'operazione di database che ha attivato il trigger interessa anche più di una riga della tabella o eventualmente nessuna riga. Di conseguenza, le pseudotabelle inserite ed eliminate hanno numeri di riga variabili (vedi esempio C:
    ).
Esempio di attivazione utente 
CREATE TRIGGER TR_USER_AF_INSUPD_StatusPruefung ON Auftrag
FOR INSERT, UPDATE
AS

/* Questo deve essere il primo comando in un trigger */
SET NOCOUNT ON

/* Qui iniziano i comandi di attivazione effettivi */

Mantenere basso il carico del server

Controllare i campi modificati con UPDATE()

Con pochissime eccezioni, si desidera monitorare solo un numero limitato di colonne in un trigger. Transact-SQL fornisce la funzione UPDATE (nome colonna) per determinare le colonne modificate. Racchiudere sempre i comandi di attivazione in un blocco di condizioni che contenga tutti i campi desiderati:

IF UPDATE(Status) OR UPDATE(Objekt) OR UPDATE (Datum)
BEGIN
  /* I comandi di attivazione */
END

Nota:

La funzione UPDATE (AGGIORNAMENTO) restituisce sempre il Falso nei trigger DELETE (ELIMINA).

SELEZIONI e AGGIORNAMENTI ottimizzati

Ridurre al minimo o ottimizzare i comandi SELECT o INSERT. Se necessario, creare degli indici nelle tabelle corrispondenti per abbreviare i tempi di esecuzione.

Solo perché la funzione UPDATE (nome colonna) restituisce True, non è necessario che la colonna sia stata modificata. Ad esempio, il comando

UPDATE Address SET Dimensione sconto = 'A' DOVE Dimensione sconto = 'A'

non si rivolge al gruppo di sconto, ma UPDATE lo fa. Se un comando SQL elaborato dipende da una modifica "reale" della colonna, è necessario prevedere ulteriori controlli. Ad esempio, il comando seguente crea una tabella temporanea con gli ID indirizzo che sono stati effettivamente modificati:

DECLARE @t TABLE (id int)
INSERT @t SELECT i.id
FROM inserted i, deleted d
WHERE i.id = d.id AND i.RabattGr <> d.RabattGr

Esempio

R: Verifica delle modifiche ed emissione di un messaggio di errore con Rollback

In questo esempio, quando si modificano le voci dell'ordine, il sistema verifica se vi sono ancora ricavi positivi. In caso contrario, viene visualizzato un messaggio di errore e la modifica viene eliminata (nota: questo controllo potrebbe anche essere eseguito in modo più efficiente con un CONTROLLO DI CONTROLLO DI CONTROLLO).

CREATE TRIGGER TR_USER_AFP_INSUPD_Ertrag ON AuftragPos
FOR INSERT, UPDATE
AS

SET NOCOUNT ON

IF ( UPDATE(VkRab) OR UPDATE(Menge) OR UPDATE(PreisEH) )
BEGIN
  IF EXISTS (SELECT * FROM inserted 
     WHERE (Menge > 0) AND (Ertrag < 0) ) BEGIN
    RAISERROR('[VENDOR:USER][ADRESS:USER] Il 
margine troppo basso!', 16,1) ROLLBACK END END
B: Creazione di una voce di registro nel server SQL

Questo log di trigger cambia alla data o allo stato dell'ordine dell'ordine. Vengono presi in considerazione solo gli ordini più vecchi di un'ora. Le informazioni vengono registrate nel registro del server SQL. Questo può essere visualizzato come file di testo in SQL Enterprise Manager o in Esplora risorse.

CREATE TRIGGER TR_USER_AF_UPD_Datum ON Auftrag
FOR UPDATE
AS

SET NOCOUNT ON

IF UPDATE(Datum) OR UPDATE(BestellStatus) 
BEGIN
  /* Verifica se esistono ordini più vecchi di uno
  ** l'ora è */
  IF EXISTS(SELECT * FROM inserted
    WHERE DATEDIFF(hour,CreateDate,GETDATE())>1 )
  BEGIN

    /* Dichiarazione delle variabili utilizzate */
    DECLARE @userid int, @nr int, @count int

    /* Determinazione del numero d'ordine e del numero di
    ** cambiato gli ordini. Se sono interessate più richieste
    ** In questo esempio viene determinato solo il numero più piccolo. */
    SELECT @nr = MIN(KopfNummer), @count = COUNT(*) FROM inserted

    /* Creare una voce in tabella cnProesses
    ** con tutte le informazioni sull'utente e sulla postazione di lavoro
    ** su cui viene eseguito il comando */
    EXEC cn_UserId @userid OUT

    /* Immissione di un messaggio di errore nel log del server SQL
    ** Il livello di gravità è 1.
    ** on trasmessi a EULANDA */
    RAISERROR('Data/OrdineStato in %d elemento/i d'ordine 
      modificato (numero d'ordine %d) 
      di %d processo (per ulteriori informazioni, guarda tabella cnProcess)',
      1,1, @count, @nr, @userid) WITH LOG

  END
END
C: Un comando di aggiornamento che non modifica alcuna riga

Il seguente script SQL mostra che un comando UPDATE non deve necessariamente cambiare riga. Per i programmatori trigger, questo significa che si deve considerare anche il caso di linee zero nelle pseudotabelle:

CREATE TRIGGER TR_USER_AR_UPD_CountTest ON Artikel
FOR UPDATE
AS

/*
** Questo trigger è usato SOLO per chiarire i valori specificati nella finestra di dialogo
** Testo descritto problema.
** Altrimenti questo NON è un trigger valido per l'utilizzo di
** con la gestione merci EULANDA®!
*/

IF UPDATE(Barcode)
  SELECT COUNT(*) [Righe interessate con modifiche dei codici a barre] 
    FROM inserted
ELSE SELECT COUNT(*) [Nessun cambio di codice a barre] FROM inserted

GO

UPDATE Artikel SET Barcode = '4711' WHERE 1 = 2

GO

DROP TRIGGER TR_USER_AR_UPD_CountTest

Vedere anche

Denominazione delle convenzioni
cn_UserId
RAISERROR Creazione di indici
utente Creazione di vincoli di controllo utente