Du refererer ikke til de indsatte eller slettede tabeller, der kun er tilgængelige i triggeren, så du returnerer selvfølgelig flere poster, som du har brug for i din forespørgsel.
Når jeg først skriver en trigger, er det, jeg gør, at oprette en midlertidig tabel kaldet #inserted (og/eller #deleted) og udfylde den med flere poster. Det skal matche designet af bordet, som udløseren vil være på. Det er vigtigt at få din midlertidige tabel til at have flere inputposter, der kan opfylde de forskellige kriterier, der påvirker din forespørgsel (så i dit tilfælde vil du have nogle, hvor sagsantallet er 0 og nogle, hvor det f.eks. ikke ville) og det ville være typisk af data indsat i tabellen eller opdateret init. SQL-server-triggere fungerer på datasæt, så dette sikrer også, at din trigger korrekt kan håndtere flere registrerings-uiinserts eller opdateringer. En korrekt skrevet trigger ville have testcases, du skal teste for at sikre, at alt sker korrekt. Din #inserted tabel skal indeholde poster, der opfylder alle disse testcases.
Skriv derefter forespørgslen i en transaktion (og rul den tilbage, mens du tester) ved at deltage i #inserted. Hvis du laver et indsæt med et udvalg, skal du kun skrive den valgte del, indtil du får det rigtige, og derefter tilføje indsætningen. Til test skal du skrive et valg fra den tabel, du indsætter i, for at se de data, du indsatte, før du ruller tilbage.
Når du har fået alt til at fungere, skal du ændre #inserted referencerne til inserted, fjerne enhver testkode og selvfølgelig rollback (muligvis hele transaktionen afhængig af, hvad du laver.) og tilføje drop og oprette trigger-del af koden. Nu kan du teste din trigger som en trigger, men du er i god form, fordi du ved, at det sandsynligvis vil fungere fra din tidligere test.