Need growth chart - SQL vs Code as solution? (1 Viewer)

Making a Chart from the data. Need advice on if it should be done in SQL language or using Code.

Have a query in place that shows the number of items with specific conditions for each month over 6 months.
e.g 4, 25, 30, 3, 1, 20 - total amount of new items added each month
This data gets plotted in Excel. Showing an Up/Down progression
The problem: This needs to be a Growth chart showing the growth.
In other words, start with 4, then 29, then 59, then 62, then 63, then 83.

The last month's value has the next month's value added.

For all my experience, I don't do Excel Charts that often. Maybe it is something for Excel.
Or, is this something the SQL language can take care of? Would it be better done using code?

what you are looking for is a Running sum, search for that see where to get stuck and comeback here with any trouble

What a difference knowing the name makes! Thanks.
It is a Running Total (a.k.a. Running Sum)

Did I miss any methods?
Excel 2013 claims to have a new chart feature for just this. Not so for earlier versions.

Excel offers two methods:
1. Download Data then create a Pivot Table using Running Total to create a new column. Then chart the Pivot Table.
2. Download Data, then program (or manually) add a column with the running total formula. Then chart the correct colums.

In TSQL:
For SQL Server 2012 - a new formula makes it oh, so simple!
For the rest of us, this article explains how to add a simple Running Total using T-SQL.
MS SQL Server T-SQL Running Totals: http://www.codeproject.com/Articles/300785/Calculating-simple-running-totals-in-SQL-Server

In Access SQL - was surprised to find this:
http://support.microsoft.com/kb/290136
Did it really say this process could take a long time to run?

Sure enough, there are many options.
The T-SQL (2008) option looks interesting. Create it, then turn it into a Linked table for Access to chart via VBA.

the access solution uses dsum which will be slow.

A better solution (for Access anyway) is to use a sub query although this can also be slow for large numbers of records. Something like


Note the above may be insufficient in real life because you may want to order by type of transaction as well - e.g. show deposits before withdrawals on a given day.

Most current versions of bigger databases like SQL Server and Oracle now a days have a function called "Partition By". These are analytic functions that allow to quickly create running sums.

The subselect method(s) indeed can take a long time to run, since the subselect needs to be ran for each record. If the table is big, it slows down considerably.
A cross join or semi-cartesian product can increase performance a little bit.
though if you have a backend in a "big brother" database using the analytics is by far prefered.