## Calculate the Running Total for the last five Transactions

 Author Message Divya Agrawal Old Hand Group: General Forum Members Points: 338 Visits: 604 Comments posted to this topic are about the item Calculate the Running Total for the last five Transactions --Divya Lynn Pettis SSC-Dedicated Group: General Forum Members Points: 32192 Visits: 38328 Good article, but let's take another approach and see what we see.Taking your sample data from your article, and using a slightly different tact, here is another way to tackle your problem given in your article. I have included your sample data, table (with a slight modification for my code), and code as well as my code.`set nocount ongoCREATE TABLE dbo.Accounts(ID int IDENTITY(1,1) primary key, -- Primary Key defaults to a clustered index, needed for this to workTransactionDate datetime,Balance money,RunningBalance money null);goinsert into Accounts(TransactionDate,Balance) values ('1/1/2000',100);insert into Accounts(TransactionDate,Balance) values ('1/2/2000',101);insert into Accounts(TransactionDate,Balance) values ('1/3/2000',102);insert into Accounts(TransactionDate,Balance) values ('1/4/2000',103);insert into Accounts(TransactionDate,Balance) values ('1/5/2000',104);insert into Accounts(TransactionDate,Balance) values ('1/6/2000',105);insert into Accounts(TransactionDate,Balance) values ('1/7/2000',106);insert into Accounts(TransactionDate,Balance) values ('1/8/2000',107);insert into Accounts(TransactionDate,Balance) values ('1/9/2000',108);insert into Accounts(TransactionDate,Balance) values ('1/10/2000',109);insert into Accounts(TransactionDate,Balance) values ('1/11/2000',200);insert into Accounts(TransactionDate,Balance) values ('1/12/2000',201);insert into Accounts(TransactionDate,Balance) values ('1/13/2000',202);insert into Accounts(TransactionDate,Balance) values ('1/14/2000',203);insert into Accounts(TransactionDate,Balance) values ('1/15/2000',204);insert into Accounts(TransactionDate,Balance) values ('1/16/2000',205);insert into Accounts(TransactionDate,Balance) values ('1/17/2000',206);insert into Accounts(TransactionDate,Balance) values ('1/18/2000',207);insert into Accounts(TransactionDate,Balance) values ('1/19/2000',208);insert into Accounts(TransactionDate,Balance) values ('1/20/2000',209);goselect * from dbo.Accounts;goprint '-- Cross Join Query --';set statistics io onSELECT Acc.ID,CONVERT(varchar(50),TransactionDate,101) AS TransactionDate , Balance, isnull(RunningTotal,'') AS RunningTotal FROM Accounts Acc LEFT OUTER JOIN (SELECT ID,sum(Balance) AS RunningTotal FROM (SELECT A.ID AS ID,B.ID AS BID, B.Balance FROM Accounts A cross JOIN Accounts B WHERE B.ID BETWEEN A.ID-4 AND A.ID AND A.ID>4)T GROUP BY ID ) Bal ON Acc.ID=Bal.ID;set statistics io offprint '-- Cross Join Query --';goprint '-- Update Query --';set statistics io ondeclare @var1 money, @var2 money, @var3 money, @var4 money, @var5 money;update dbo.Accounts set @var5 = @var4, @var4 = @var3, @var3 = @var2, @var2 = @var1, @var1 = Balance, RunningBalance = isnull(@var1 + @var2 + @var3 + @var4 + @var5, 0);set statistics io offprint '-- Update Join Query --';goprint '-- Select After Update Query --';set statistics io onselect * from dbo.Accounts;set statistics io offprint '-- Select After Update Query --';godrop table dbo.Accounts;goset nocount offgo`My results match yours in the article, but what I also wanted to include here were the stats I also had collected using statistic io on (included in the above code).-- Cross Join Query --Table 'Accounts'. Scan count 17, logical reads 74, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.-- Cross Join Query ---- Update Query --Table 'Accounts'. Scan count 1, logical reads 2, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.-- Update Join Query ---- Select After Update Query --Table 'Accounts'. Scan count 1, logical reads 2, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.-- Select After Update Query --I'll leave further assessment of the different approaches to others. For me, I just wanted to see what might be different. Lynn PettisFor better assistance in answering your questions, click hereFor tips to get better help with Performance Problems, click hereFor Running Totals and its variations, click here or when working with partitioned tablesFor more about Tally Tables, click hereFor more about Cross Tabs and Pivots, click here and hereManaging Transaction LogsSQL Musings from the Desert Fountain Valley SQL (My Mirror Blog) Jacob Luebbers SSC-Addicted Group: General Forum Members Points: 468 Visits: 1215 @Lynn:Gold Regards,Jacob ChiragNS SSCrazy Group: General Forum Members Points: 2879 Visits: 1865 Brilliant Divya and Lynn "Keep Trying" Hugo Kornelis SSCrazy Eights Group: General Forum Members Points: 9511 Visits: 11835 There is a huge problem with this technique. IDENTITY values are not guaranteed to be consecutive; for a variety of reasons there may be gaps. Those will invalidate the results from this query.On SQL Server 2005 and above, using ROW_NUMBER() is the adviced technique. On SQL Server 2000 and below - well, let's just say that the required query will be ugly... Hugo Kornelis, SQL Server MVPVisit my SQL Server blog: http://sqlblog.com/blogs/hugo_kornelis Ninja's_RGR'us One Orange Chip Group: General Forum Members Points: 25075 Visits: 9671 Hugo, are you talking about the quirky update for 2000? Hugo Kornelis SSCrazy Eights Group: General Forum Members Points: 9511 Visits: 11835 Ninja's_RGR'us (11/27/2008)Hugo, are you talking about the quirky update for 2000?Hi Ninja's_RGR'us,No. As far as I know, UPDATE is not quirky at all in SQL Server 2000. What do you mean by "quirky update"?What I was refering too is the lack of ROW_NUMBER() in SQL Server 2000. This means you'll either have to take your chance with IDENTITY, at the risk of gaps, as the author of this article did; or you have to use a correlated subquery to calculate the row number on the fly, which can result in dramatic performance as the amount of rows grows. Plus, the queries tend to get long and hard to understand. Hugo Kornelis, SQL Server MVPVisit my SQL Server blog: http://sqlblog.com/blogs/hugo_kornelis Ninja's_RGR'us One Orange Chip Group: General Forum Members Points: 25075 Visits: 9671 I meant this by quirky update : Update table set @Var = UpdatedColumn = @Var + WhateverIttakesToEvalutateThisVariableThis must be used with a index hint on a temp table to be sure that nothing goes wrong...That's a way to make a running total... the case statement here would be quite interesting though ;-P. Hugo Kornelis SSCrazy Eights Group: General Forum Members Points: 9511 Visits: 11835 Ninja's_RGR'us (11/27/2008)I meant this by quirky update : Update table set @Var = UpdatedColumn = @Var + WhateverIttakesToEvalutateThisVariableThis must be used with a index hint on a temp table to be sure that nothing goes wrong...That's a way to make a running total... the case statement here would be quite interesting though ;-P.Oohh, that one.You know that this "trick" is neither documented nor supported, do you?(Clarification: "UPDATE ... SET @var = column = expression" is documented and supported, but the effects of the same variable in the expression are not - and given the official intent of an UPDATE statement, the results people currently get in 99% of all cases could be considered a bug). Hugo Kornelis, SQL Server MVPVisit my SQL Server blog: http://sqlblog.com/blogs/hugo_kornelis Ninja's_RGR'us One Orange Chip Group: General Forum Members Points: 25075 Visits: 9671 Yup that's the one!Thanks for the clarifications!