SQL ROLLUP

I have the following query:

SELECT   DATEPART(yyyy, ReferredOn) AS ReferredOnYear, SimpleName, SUM(Count) AS Count, Outcome
FROM         dbo.Utilization
GROUP BY DATEPART(yyyy, ReferredOn), SimpleName, Outcome
HAVING      (Outcome = N'Completed')
ORDER BY ReferredOnYear

This makes a nice summary of each SimpleName for each year. I would like to have a summary row for each year after its grouping. I'm not sure how to approach this. I tried a rollup but it didn't look as expected.

Thanks.
LVL 1
LCNWAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

lcohanDatabase AnalystCommented:
You mean like this?

SELECT q.ReferredOnYear, q.SimpleName, q.[Count], q.Outcome
FROM
(
      SELECT   DATEPART(yyyy, ReferredOn) AS ReferredOnYear, SimpleName, SUM([Count]) AS [Count], Outcome
      FROM     dbo.Utilization
      GROUP BY DATEPART(yyyy, ReferredOn), SimpleName, Outcome
      HAVING      (Outcome = N'Completed')
      --ORDER BY ReferredOnYear
) q
GROUP BY q.ReferredOnYear
ORDER BY q.ReferredOnYear;
0
LCNWAuthor Commented:
lcohan,

I'm unable to get that to work. It doesn't identify all of the columns or the table properly.

After fixing the syntax it returns the original data set with no sum rows.



I think grouping sets may be the way to go.
0
LCNWAuthor Commented:
Grouping Sets appears to work, but when I add the HAVING clause it kills it?
0
10 Tips to Protect Your Business from Ransomware

Did you know that ransomware is the most widespread, destructive malware in the world today? It accounts for 39% of all security breaches, with ransomware gangsters projected to make $11.5B in profits from online extortion by 2019.

PortletPaulfreelancerCommented:
'grouping sets' is most probably the way to go for this

It will look something like this, you may need to fiddle with the sets to get the desired number of sub-totals. Other comments included below:
SELECT
        DATEPART(yyyy, ReferredOn) AS ReferredOnYear
      , SimpleName
      , SUM([COUNT]) AS [Count] --<< count is a reserved word it should be within []
      , Outcome
FROM dbo.Utilization
WHERE (Outcome = N'Completed') --<< use where instead of having for this
GROUP BY  GROUPING SETS (
                           ( DATEPART(yyyy, ReferredOn), SimpleName , Outcome )
                         , () --<< grand total
                        )
--ORDER BY
--        ReferredOnYear --<< you may need to reconsider how it gets sorted

Open in new window

useful examples here
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
LCNWAuthor Commented:
I got it working prior and added your WHERE and it is still good.

Why do you have to use WHERE instead of HAVING? Just curious.

That's the exact blog I was using.
0
LCNWAuthor Commented:
Here's what I used and it works. Thanks.


USE [Database]

SELECT DATEPART(yyyy, ReferredOn) AS ReferredOnYear, ISNULL(SimpleName, 'ALL'), SUM(Count) AS Count, ISNULL(Outcome,'Completed')
FROM dbo.Utilization
WHERE (Outcome = 'Completed')
GROUP BY GROUPING SETS
(
   (
    DATEPART(yyyy, ReferredOn)
    ,SimpleName
    ,Outcome
   ),
   (
    DATEPART(yyyy, ReferredOn)
    
   )
)

Open in new window

0
PortletPaulfreelancerCommented:
>>Why do you have to use WHERE instead of HAVING? Just curious.

You can use both, but they do slightly different things.

The where clause is executed BEFORE aggregations, so it helps to reduce the workload.

The having clause is applied AFTER the aggregations and that is why you can reference aggregated items here ( e.g. having count(*) > 1 ) which you cannot do in a where clause.

So they both have their place in a query, where is to filter for records in the normal way, having is to make decisions about the aggregate information.

{+edit, sorry}
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
SSRS

From novice to tech pro — start learning today.