Hi Every one,
The data A is
Date | AZ |
1/1/2015 | 10 |
1/1/2016 | 45 |
1/1/2017 | 41 |
1/1/2018 | 41 |
1/1/2019 | 46 |
1/1/2020 | 65 |
1/1/2021 | 43 |
1/1/2022 | 59 |
I want it to be
Date | AZ |
1/1/2015 | 10 |
1/1/2016 | 45 |
1/1/2017 | 41 |
1/1/2018 | 41 |
1/1/2019 | 46 |
1/1/2020 | 65 |
1/1/2021 | 43 |
1/1/2022 | 59 |
Total | 350 |
The are many ways of how to achieve this (proc print, proc report, proc tabulate, proc sql, proc summary, ....). What have you tried so far and where did you get stuck?
If date variable is character type, that would be easy. otherwise you need other skill.
data have; input Date : $20. AZ ; cards; 1/1/2015 10 1/1/2016 45 1/1/2017 41 1/1/2018 41 1/1/2019 46 1/1/2020 65 1/1/2021 43 1/1/2022 59 ; run; data want; set have end=last; sum+az;output; if last then do; date='Total';az=sum;output; end; drop sum; run;
Xia Keshan
Please, don't store totals in the same table as the detail data.
As Patrick suggests, creating totals is the work for reports, not data manipulation steps.
I actually disagree with this. A case in point is my deliverables, I always store a dataset almost exactly as it is shown in the output, so that this can be independently QC'd. Reduces the amount of QC done on the output file. Of course this wouldn't alter the source data, just the processed data going into the output files. Of course, something simple like this you could do with proc report for instance and have that output a dataset, however as it gets more complicated...
Storing summary rows in a table is... let's call it "very uncommon" and I would assume you'd be pretty alone with such an approach.
I strongly side with LInus and Patrick.
I've had considerable experience with managing aggregated data stores, and this architecture will greatly increase the chances that you'll produce incorrect summarized results in the future.
However, if you're going to do this, use something like the _TYPE_ variable that PROC MEANS creates, to provide an unambiguous indication of the role that each row plays.
Tom
Possibly a difference in industries/usage there then. My outputs are of the form:
col1 col2 treat1 treat2 total
xyz x n (n%) n (n%) n (%)
...
And some other slightly more complicated. I am not for a moment suggesting this should be stored in a data warehouse or what not, this is purely a dataset to support an output, and whilst with some compute blocks you may be able to get the aforementioned output we need to retain a useable copy of this so an independent QC programmer can re-create the same data for a comparison.
Note, I am not changing the raw data, merely the output supporting dataset.
For temporary tables which existence is purely for report out, then it serves a purpose.
So perhaps we agree on this matter for the main situations...?
Save $250 on SAS Innovate and get a free advance copy of the new SAS For Dummies book! Use the code "SASforDummies" to register. Don't miss out, May 6-9, in Orlando, Florida.
Need to connect to databases in SAS Viya? SAS’ David Ghan shows you two methods – via SAS/ACCESS LIBNAME and SAS Data Connector SASLIBS – in this video.
Find more tutorials on the SAS Users YouTube channel.