• A couple of quick points:

    1. Since you're a first time poster, you should understand that to get better, faster and more accurate help you should follow the first link in Jeff signature to learn forum etiquette for providing DDL and consumable sample data (like in my first SQL shown below).

    2. Jeff's article on Hierarchies on Steroids is incredibly useful for complex hiearchies were a lot of information between nodes must be retained. However I think it may be a bit overkill in this case where all you need to do is sum the children of a parent to one level deep (assuming this is right).

    DDL and consumable sample data:

    DECLARE @T1 TABLE

    (relationID INT, meterID INT, parentID INT, childID INT)

    DECLARE @T2 TABLE

    (dataID INT, meterID INT, [date] DATE, amount INT)

    INSERT INTO @T1

    SELECT 1 , 1 , null , 2

    UNION ALL SELECT 2 , 1 , null , 3

    UNION ALL SELECT 3 , 2 , 1 , 4

    UNION ALL SELECT 4 , 2 , 1 , 5

    UNION ALL SELECT 5 , 3 , 1 , 6

    UNION ALL SELECT 6 , 3 , 1 , 7

    UNION ALL SELECT 7 , 4 , 2 , null

    UNION ALL SELECT 8 , 5 , 2 , null

    UNION ALL SELECT 9 , 6 , 3 , null

    UNION ALL SELECT 10 , 7 , 3 , null

    INSERT INTO @T2

    SELECT 1 , 1 , '2013-01-01' , 100

    UNION ALL SELECT 2 , 2 , '2013-01-01' , 60

    UNION ALL SELECT 3 , 3 , '2013-01-01' , 40

    UNION ALL SELECT 4 , 4 , '2013-01-01' , 35

    UNION ALL SELECT 5 , 5 , '2013-01-01' , 25

    UNION ALL SELECT 6 , 6 , '2013-01-01' , 15

    UNION ALL SELECT 7 , 7 , '2013-01-01' , 25

    A possibly simpler solution than the one provided by Mr. AsiaIndian, made possible because you keep all of your child nodes in the relations table:

    SELECT a.meterID, b.[date]

    ,MeterAmt=MAX(b.amount)

    ,SumOfChildren=SUM(c.amount)

    FROM @T1 a

    INNER JOIN @T2 b ON a.meterID = b.meterID

    LEFT JOIN @T2 c ON a.childID = c.meterID

    GROUP BY a.meterID, b.[date]

    Change the LEFT JOIN to an INNER JOIN if you don't want leaf nodes displayed in the results.


    My mantra: No loops! No CURSORs! No RBAR! Hoo-uh![/I]

    My thought question: Have you ever been told that your query runs too fast?

    My advice:
    INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
    The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.

    Need to UNPIVOT? Why not CROSS APPLY VALUES instead?[/url]
    Since random numbers are too important to be left to chance, let's generate some![/url]
    Learn to understand recursive CTEs by example.[/url]
    [url url=http://www.sqlservercentral.com/articles/St