I struggled with some SQL tonight and learned:
- My notes here poorly describe how to cast more than one column into a cursor. Do so like this:
DECLARE curs CURSOR FOR SELECT TOP 10 Ying, Yang From dbo.[Baz]
OPEN curs
FETCH NEXT FROM curs into @unalterednumber, @somethingelse
...that is by separating the variables for each column with commas everywhere I otherwise have merely @unalterednumber in my blog posting. - something painful to get used to in GROUP BY/HAVING statements is that in scenarios where you know a column just repeats its value universally you cannot... oh, wait... I realize what I am about to say is not true as I type it. If a value is just going to repeat universally, you can show it as a column which means you will have to include it in the GROUP BY. This act will not screw up the report as what the reporting was before adding the extra condition (which adds nothing as all of the values it concerns are identical for the record sets it would have come up with anyways) varies not at all in terms of numbers of rows or aggregation
- what I was going to say, inappropriately, was that if you need to show the consistently repeating value out of such a column, you will need to nest the GROUP BY/HAVING thing inside the WITH cause of a CTE and then join on the appropriate table to end up selecting this extra column
- that is if the extra column is of, say, a varchar type... if it is of a numeric type you may get the repeating column as a column in the GROUP BY/HAVING statement without specifying it in the GROUP BY by using the MIN aggregate function ...but, again, you don't need to do this
No comments:
Post a Comment