Not exactly sure what you are basing "rank" and "percentage" on, but maybe you could combine your approaches and reduce the overhead enough to be acceptable:

SELECT

...

Also, it's risky to base your security practices on read-only access.

What happens a year from now when the app needs changed to allow UPDATEs / DELETEs? Your security approach...

Certain conditions make a plan uncacheable as well.

For example, a literal > 8K. That used to be just a weird quirk, not really applicable in real life ... but...

That's not true.

Yes, but sometimes users need the capability to UPDATE and, on...

You could try this and see what it does:

insert into combined_stats_agg

SELECT r.mf_cd+2000 as mf_cd, r.mkt_id,

r.mf_dt, c.mf_nm, r.mf_val

FROM (

...

Order1, Line1, 1/1/2010, 1/13/2010, 0 --why 0?

Order1, Line2, 1/30/2010, 2/15/2010, 17 --1/30 - 1/13?

Order1, Line3, 2/15/2010, 2/17/2010, 2 --?? why not 0 for 2/15 - 2/15

Order2, Line1, 1/1/2010, 1/5/2010, 4...

60 rows is probably not a large enough sample to show a performance affect.

I would think GROUP BY would have to be faster than ROW_NUMBER(), since SQL doesn't have to partition and generate row numbers, but it would be interesting to compare the...

SELECT CAST(CAST(Duration AS decimal(11, 2)) / 3600 AS decimal(6, 2)) AS DurationInHrs

select dataId, code, imageName, min(loadid)

from @t1

group by dataId, code, imageName

Nope, nothing better. NULLs must be checked separately.

Lol. Not sure, just an idea that pops into your head.

When you look at the output of version, you see that the first four consecutive digits in the result...

Your rollback will likely take at least roughly twice as long as the original updates.

Do you have an index on rc.revno?

For...

SELECT SUBSTRING(@@VERSION, PATINDEX('%[0-9][0-9][0-9][0-9]%', @@VERSION), 4)