Stephan,

Zo te zien probeer je een tabel met cumulatieve gegevens bij te houden. Ik heb een script gemaakt om een mogelijke oplossing te demonstreren.

create table Artikel(ArtikelID int, GroepID int, Prijs decimal(18,2))
create table Groep(GroepID int, sumPrijs decimal(18,2))

Create trigger tr_UpdateGroep on Artikel for Insert, Update, Delete
as
  Update Groep 
    Set sumPrijs = Artikel.Totaal
  From
  ( 
   Select 
      Artikel.GroepID, 
      Sum(Artikel.prijs) Totaal 
   From Artikel 
   Join inserted on inserted.groepID = Artikel.groepID 
   Group by Artikel.GroepID 
  ) Artikel 
  Where Groep.GroepID = Artikel.GroepID

insert into Groep(GroepID)
Select 1
union all
Select 2

insert into Artikel(ArtikelID, GroepID, Prijs)
Select 1, 1, 10.00
union all
select 2, 1, 15.10
union all
select 3, 2, 20.50
union all
select 4, 2, 19.95

Je kunt na het draaien van dit script, in een testdatabase uiteraard , de prijzen in de Artikel tabel updaten waarna de trigger het sumPrijs veld van de bijbehorende groepen zal aanpassen.
Het werkt ook als je nieuwe artikelen toevoegd of delete.

De truuk is dat je in je update statement een Select statement achter de FROM zet waardoor je een soort van view on the fly maakt. De velden die je maakt in dit statement kun je vervolgens weer gebruiken in het update statement. Zo kun je toch een GROUP BY gebruiken in combinatie met een UPDATE statement.
Ik join in mijn voorbeeld INSERTED zodat alleen de groepen die gewijzigd zijn opnieuw worden doorgerekend.

Groeten,

André

p.s.: Mocht dit niet helemaal zijn wat je zocht. Probeer dan (korte) voorbeeld scripts mee te posten waarmee iemand het scenario kan naspelen, net als ik gedaan heb in mijn uitleg.
(Mijn voorbeeld zal niet helemaal jouw situatie weergeven uiteraard, maar hopelijk kun je er wel een oplossingsrichting voor je probleem uithalen)

Ik heb nog een alternatief, onderstaande trigger zal het verschil tussen inserted en deleted uitrekenen en het totaal updaten.
(Het totaal wordt dus niet steeds opnieuw uitgerekend aan de hand van alle records voor de gewijzigde groep in de ARTIKEL tabel)

Dit werkt iets beter als je bijvoorbeeld veel records hebt bij ARTIKEL.
Wel zul je als er eenmaal een foutieve waarde in staat een reparatiequery moeten draaien omdat de trigger alleen de verschillen kan verwerken.

Hoi Andre, volgens mij ben ik eruit. De eerste test zijn hoopgevend..

Waardoor het bij mij steeds verkeerd ging, is dat ook een controle uit moet voeren op de actieve periode in het voorbeeld zou dat zijn dan alle joins uitgebreid werden met
inserted.jaar=groep.jaar en deleted.jaar=groep.jaar

Nog een kleine vraag:
Jouw eerste oplossing berekend wel steeds alles opnieuw? Klopt?
De tweede oplossing voegt alleen het verschil (positief dan wel negatief) toe. Klopt?

Ik heb vooralsnog voor de eerste oplossing gekozen.

THX