Timeline for How to get a row_number to have the behavior of dense_rank
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 23, 2013 at 14:51 | vote | accept | Taryn | ||
| May 23, 2013 at 5:07 | history | tweeted | twitter.com/#!/StackDBAs/status/337434625070731264 | ||
| May 22, 2013 at 23:52 | comment | added | Taryn |
@AaronBertrand No we are not filtering the parameters that way. The grp table has columns with different indicators, let's say the group is restricted to certain users based on the group owner, we are verifying that the proc only is returning the rows that the person has access to...there are several ORs in the where clause but it is not a check between the @param is null or column = @param.
|
|
| May 22, 2013 at 23:46 | comment | added | Aaron Bertrand |
Is the where filtering of the variety @param IS NULL OR Column = @param?
|
|
| May 22, 2013 at 23:45 | comment | added | Taryn |
@AaronBertrand The order by is exactly what I placed in this post. The stored proc has a large block of where filtering is used when the initial row_number is applied to the result.
|
|
| May 22, 2013 at 23:40 | comment | added | Aaron Bertrand | If your order by decisions are more complex, or if you have dynamic search criteria as well, it may be better to branch or to use dynamic SQL. You give SQL Server a better fighting chance optimizing the different variations separately then either (a) recompiling every time or (b) trying to find some magical, optimal plan that satisfies all the variations. | |
| May 22, 2013 at 23:17 | comment | added | Taryn | @PaulWhite This was a small piece of a stored proc. I trimmed down the details significantly to get a solution to this specific problem. I would be open to other suggestions/solutions. | |
| May 22, 2013 at 21:06 | answer | added | Aaron Bertrand | timeline score: 7 | |
| May 22, 2013 at 21:05 | history | asked | Taryn | CC BY-SA 3.0 |