Akkumulere værdier i kolonne

Det tror jeg ikke at man kan hvis det skal være i rent SQL. Hvis der kommer et forslag i SQL som virker, vil jeg meget gerne høre om det.

Du kan selvfølgelig altid skrive en TRANSACT-SQL-procedure.

men der betragtes null da som 30 ???

Nej da - 10=10, 10+20=30, 10+20+null=30, 10+20+null+30=60

Du skal anvende funktionen ISNULL(VALUE,0) de steder i din SQL, hvor du anvender VALUE

larildsen-->> Det ændrer jo ikke noget på at speder vil have akkumuleret værdier!
Måden det kan løses på er som darkstar siger, ved at bruge en sp og evt. cursor.

Hvis nu tabellen hedder nullcheck så

select n1.id, (select sum(n2.value) from nullcheck n2 where n2.id <= n1.id) as value from nullcheck n1 order by n1.id

evt.

select n1.id, (select sum(isnull(n2.value,0)) from nullcheck n2 where n2.id <= n1.id) as value from nullcheck n1 order by n1.id

larildsen>>>> det tager jeg hatten af for. Jeg tror at den holder. Der bliver ladet en forfærdelig bunke forespørgseler og jeg tror at det er meget sandsynligt at det går hurtigere hvis man selv laver beregningen, men alligevel...

_darkstar_>>>> Jeg er helt klar over, at der bliver lavet mange opslag, og at det kan klares meget bedre client-side, men hvis der er få rækker i tabellen, og forespørgslen ikke kører ret ofte, så mener jeg løsningen er anvendelig.
Hvis tabellen er stor, eller tingene skal køre ofte, så skal det løses programmatisk

Hvis man er ude i en situation som denne, er det sandsynligvis fordi datamodellen er for dårlig. Kære venner, lad os IKKE bruge tid på overhovedet at lave sådanne ting med SQL, det er det sq ikke beregnet til !

øh, der er nu ikke noget galt med datamodellen, men når du arbejder med standardapplikationer som f.eks. Crystal Reports el. lign. så er der situationer, hvor det er meget mere hensigtsmæssigt (af vedligeholdelseshensyn) at henlægge logikken til SQL.

I princippet burder der da ikke være noget galt i sådan en forespørgsel. Filosofien er jo at alt hvad man kan klemme ind i SQL, skal optimizeren prøve at håndtere.

Grunden til at flere her er imod at gøre det, er fordi at vi (sandsynligvis med rette!) har en idé om at det kan optimizeren ikke klare. Det burde den altså bare kunne...

En anden database som jeg kender kan lave nummeret, og hvis Larry Ellison's database kan, og der er "demand" i markedet for det, så kommer SQL Server også til at kunne det i en fremtidig release.
Spørgsmålet er, kan det betale sig at rafinere query'et mere end mit forslag, eller ej. Det kan der jo regnes på, såfremt man har et overblik over hvor ofte statementet bliver udført, og hvor "dyrt" det er at udføre.
Det ville være en drøm, hvis aggregerings funktionerne blev lidt mere udviklet.