At least for me personally, I never upgrade in-place. Create a new VM (or get a new server) and install the new SQL version on a fresh Windows install, then backup/restore databases across + copy server-level objects (logins, jobs, certs etc.). It might be less of an issue these days but I know older versions (2005 and earlier mostly) sometimes weren't entirely reliable after an in-place upgrade (blue screens, access violations, things like that)
I freely admit I could well be too paranoid and/or an old curmudgeon
RECENT POSTS Compare Plans with SSMS 2016+ 2017-01-25 File Growth Analysis via Default Trace 2017-01-03 CROSS APPLY as an alternative to UNPIVOT 2016-08-12 Gaps between SQL Server Agent Jobs 2016-06-10 Obtaining machine names for failed logins 2016-06-10
so, my answer is kinda shite. Should I nuke it from orbit and act like I never wrote it? Can you even understand the requirements from the OP? It feels like a bowl of spaghetti to me.
I mean, I think I have the answer correct, I just am not really sure.
I spent a bunch of time on that pile'o'rubble. It could have been so much easier if the column names in his three tables were named in some kind of sane manner. Foreign keys from AggregationChildID to CodeID and AggregationID to CodeID just scream stupid to me.
I saw that Mr White edited that question, and thought "if Paul upvoted it, it must be a good question". I assumed, incorrectly it would seem, that he was the one that upvoted it. I can only assume now that the OP used his own sock-puppet to upvote it.
I should have realized the trouble I was in when I started the answer with "I had a hard time parsing your query,"
@PaulWhite ahhh, so it was you... ;-) no worries at all. It was deceptively simple looking at first glance, and like you say it does have DDL, which is a bonus!