U verwijst niet naar de ingevoegde of verwijderde tabellen die alleen beschikbaar zijn in de trigger, dus u retourneert natuurlijk meer records dan u in uw query nodig hebt.
Wanneer ik voor het eerst een trigger schrijf, maak ik een tijdelijke tabel met de naam #inserted (en/of #deleted) en vul ik deze met verschillende records. Het moet overeenkomen met het ontwerp van de tafel waarop de trigger zal staan. Het is belangrijk om ervoor te zorgen dat uw tijdelijke tabel verschillende invoerrecords heeft die mogelijk voldoen aan de verschillende criteria die van invloed zijn op uw zoekopdracht (dus in uw geval wilt u sommige waar het aantal gevallen 0 zou zijn en sommige waar dit bijvoorbeeld niet zou zijn) en dat zou typisch zijn van gegevens ingevoegd in de tabel of bijgewerkte init. SQL-servertriggers werken op gegevenssets, dus dit zorgt er ook voor dat uw trigger meerdere record-uiinserts of -updates correct kan verwerken. Een correct geschreven trigger zou testgevallen hebben die u moet testen om er zeker van te zijn dat alles correct gebeurt, uw #inserted-tabel moet records bevatten die aan al die testgevallen voldoen.
Schrijf vervolgens de query in een transactie (en rol deze terug terwijl u aan het testen bent) en voeg u bij #inserted. Als je een insert maakt met een select, schrijf dan alleen het select-gedeelte totdat je dat goed hebt gedaan, en voeg dan de insert toe. Schrijf voor het testen een selectie uit de tabel die u invoegt om de gegevens te zien die u hebt ingevoegd voordat u terugdraait.
Zodra je alles werkend hebt gekregen, verander je de #ingevoegde referenties in ingevoegd, verwijder je alle testcodes en natuurlijk de rollback (mogelijk de hele transactie afhankelijk van wat je doet.) en voeg je de drop toe en creëer je een triggergedeelte van de code. Nu kun je je trigger testen als een trigger, maar je bent in goede vorm omdat je weet dat het waarschijnlijk werkt op basis van je eerdere testen.