Non fai riferimento alle tabelle inserite o eliminate che sono disponibili solo nel trigger, quindi ovviamente stai restituendo più record di cui hai bisogno nella tua query.
Quando scrivo per la prima volta un trigger, quello che faccio è creare una tabella temporanea chiamata #inserted (e/o #deleted) e popolarla con diversi record. Dovrebbe corrispondere al design della tabella su cui si troverà il trigger. È importante fare in modo che la tua tabella temporanea abbia diversi record di input che potrebbero soddisfare i vari criteri che influenzano la tua query (quindi nel tuo caso ne vuoi alcuni in cui il conteggio dei casi sarebbe 0 e altri in cui non lo sarebbe, ad esempio) e questo sarebbe tipico di dati inseriti nella tabella o aggiornati init. I trigger del server SQL operano su set di dati, quindi ciò garantisce anche che il trigger possa gestire correttamente più uiinsert o aggiornamenti di record. Un trigger scritto correttamente dovrebbe avere casi di test che devi testare per assicurarti che tutto avvenga correttamente, la tua tabella #inserted dovrebbe includere record che soddisfano tutti quei casi di test.
Quindi scrivi la query in una transazione (e esegui il rollback durante il test) unendola a #inserted. Se stai eseguendo un inserto con una selezione, scrivi solo la parte selezionata finché non lo ottieni correttamente, quindi aggiungi l'inserto. Per il test, scrivi un select dalla tabella in cui stai inserendo per vedere i dati che hai inserito prima del rollback.
Una volta che tutto funziona, cambia i riferimenti #inserted in insert, rimuovi qualsiasi codice di test e, naturalmente, il rollback (possibilmente l'intera transazione dipende da ciò che stai facendo.) e aggiungi il drop e crea una parte trigger del codice. Ora puoi testare il trigger come trigger, ma sei in buona forma perché sai che probabilmente funzionerà dai tuoi test precedenti.
