Thanks, I've added this to the google doc and basically created a "flattened" section. 😊
Original Message:
Sent: 11/13/2025 2:17:00 AM
From: Robert Lang
Subject: RE: What's your favorite expression, case statement, trick?
I've also used windowing functions to "flatten" results in a manner similar to the one described here, and I thought it might be useful for folks unfamiliar with this technique to know that the "Distinct" box should be checked in the query properties (or however the user would add the DISTINCT keyword to the Select statement at the top level of the query), since the windowing functions themselves aren't actually flattening anything; rather, they're just generating a constant value (the one corresponding to the row sought after within the window) in the field created by the expression.
For example, you'd initially get something like the following table for the first two IDs, assuming for illustrative purposes only 3 values for TREE_NODE ('GENERALFEES', 'TECHNOLOGY', and 'OTHER')-these values make up the "window" of the windowing function (i.e., the group of rows, or partitions, defined by the field specified in the PARTITION BY clause, which in this case is EMPLID):
EMPLID GENERAL_FEES TECHNOLOGY OTHER
0000001 $159.00 $224.12 $22.37
0000001 $159.00 $224.12 $22.37
0000001 $159.00 $224.12 $22.37
0000002 $115.00 $126.70 $72.50
0000002 $115.00 $126.70 $72.50
0000002 $115.00 $126.70 $72.50
Applying the DISTINCT keyword would then deduplicate the table by all fields, resulting in the following, flattened/unpivoted/widened version of the above:
EMPLID GENERAL_FEES TECHNOLOGY OTHER
0000001 $159.00 $224.12 $22.37
0000002 $115.00 $126.70 $72.50
It's important to note, however, that any other fields excluded from the Select statement but that exist in the records used in the query and that vary on the partitioning field may produce more duplicates, therefore requiring a more complex windowing function to achieve the fully flattened result, typically by adding said field or fields to the PARTITION BY clause as applicable. In the case of an ordered windowing function (e.g., NTH_VALUE), the ORDER BY clause is important here.
------------------------------
Robert Lang
Research Analyst
Duke University
------------------------------
Message from the HEUG Marketplace:
------------------------------
Find, Review, and Engage with Higher Education-focused solution providers, products, and services using the HEUG Marketplace.
------------------------------
Original Message:
Sent: 11-12-2025 11:59 AM
From: Kendall Vance
Subject: What's your favorite expression, case statement, trick?
I find this manual unpivot trick comes in handy. If we have a field (e.g. "TREE_NODE" that contains values like 'GENERALFEES' , 'TECHNOLOGY' , etc, and our user wants those amounts broken out in separate columns, with one row per emplid:
expr1:
SUM(
CASE WHEN A.TREE_NODE = 'GENERALFEES' THEN A.TP_AMT ELSE 0 END
) OVER (PARTITION BY A.EMPLID) AS GENERAL_FEES
expr2:
SUM(
CASE WHEN A.TREE_NODE = 'TECHNOLOGY' THEN A.TP_AMT ELSE 0 END
) OVER (PARTITION BY A.EMPLID) AS TECHNOLOGY AS TECHNOLOGY
etc. etc.
Note: since this method uses window functions, don't check "Aggregate Function" in the Expression Properties or Query Manager will get angry.
Kendall Vance
IT Technical Associate for Financial Aid Reporting
Northern Illinois Univ
------------------------------
Kendall Vance
IT Technical Associate for Financial Aid Reporting
Northern Illinois University
------------------------------
Message from the HEUG Marketplace:
------------------------------
Find, Review, and Engage with Higher Education-focused solution providers, products, and services using the HEUG Marketplace.
Original Message:
Sent: 10-30-2025 11:54 AM
From: Dana Pawlowicz
Subject: What's your favorite expression, case statement, trick?
What's your favorite trick, case statement, expression in SQL (or PS Query)? If you have a favorite trick (or treat), please share it!
Mine is still the one that Jeffrie Brooks shared in a FA post awhile back to get your sum totals to stop multiplying by the number of rows of data coming back. I've been using it ever since and I LOVE it. Thank you, Jeffrie!
SUM(A.OFFER_AMOUNT)*COUNT(DISTINCT A.EMPLID || A.INSTITUTION || A.AID_YEAR || A.ITEM_TYPE || A.ACAD_CAREER)/COUNT(*)
Since this was on a different forum, I'm copying Jeffrie's total response below instead of linking to the post:
So this solution is a bit unconventional but it has worked for me for a couple years now with our FA tables.
As you mentioned the amounts are multiplied by the number of rows being rolled up by the aggregate, so what we need to do is come up with the math that divides it by that same number again. After quite a bit of work, I came up with the following statement that seems to accomplish this for us. This example uses STDNT_AWARDS - which is important because the KEY fields play a big role in this.
SUM(A.OFFER_AMOUNT)*COUNT(DISTINCT A.EMPLID || A.INSTITUTION || A.AID_YEAR || A.ITEM_TYPE || A.ACAD_CAREER)/COUNT(*)
So what is it doing? Its taking the SUM that you've been stuck with and DIVIDES that number by each row in the QUERY - - - "/COUNT(*)"
That number actually ends up being too small. So we need to take that number and multiply it by the distinct key fields that are on the table that we want the SUM. - - - *COUNT(DISTINCT A.EMPLID || A.INSTITUTION || A.AID_YEAR || A.ITEM_TYPE || A.ACAD_CAREER). The result should be what you are looking for.
With different tables, you just replace the concatenated KEY fields.
For STDNT_AWRD_DSB, the expression becomes: SUM(A.OFFER_BALANCE)*COUNT(DISTINCT A.EMPLID || A.INSTITUTION || A.AID_YEAR || A.ITEM_TYPE || A.ACAD_CAREER || A.DISBURSEMENT_ID)/COUNT(*)
For STDNT_CAR_TERM it could look like SUM(A.UNT_TAKEN_PRGRSS)*COUNT(DISTINCT A.EMPLID || A.INSTITUTION || A.ACAD_CAREER || A.STRM)/COUNT(*)
It has worked really well as a work-around for me, with these tables and in our system. I would strongly recommend validating the data when you run it, especially if you are trying to apply this solution to other tables.
------------------------------
Dana Pawlowicz
Business Systems Analyst Sr - ERP
University of Cincinnati
------------------------------
Message from the HEUG Marketplace:
------------------------------
Find, Review, and Engage with Higher Education-focused solution providers, products, and services using the HEUG Marketplace.
------------------------------