It has no dependencies because it sorts the values again (as I understood the q).  If you have a lot of data that has already been sorted, that...

IIF is a corruption of SQL syntax to make other developers feel more comfortable.

A terrible idea, in my opinion.  Oracle's done the same thing to PL/SQL (Oracle equivalent of T-SQL),...

Gotta admit, I'm not a fan of PIVOT nor UNPIVOT.  I just don't care for the syntax / approach.  It seems counter-intuitive to me, naturally YMMV.

It has no dependencies because it sorts the values again (as I understood the q).  If you have a lot of data that has already been sorted, that may not...

Here's code that relies on the sequential ordering of the ID column of the underlying data set.  You could generate ID using a SEQUENCE if nothing else to insure it...

I'm not aware of anything that does that, and certainly not well.

For a SQL instance managed by Azure, there is some index tuning automatically done, but it's pretty limited.

You can...

It's both reasons that it's faster.  To pretend that the shared locks on rows don't take any time is just not true.  It may be small overhead, but...

Great, glad it helped.

Btw, note that you must ALWAYS use the alias in the UPDATE statement when using a join in an UPDATE.

--WRONG!!

UPDATE Brs --<<--WRONG!! MUST be (alias) B

SET HrsHKB...

READUNCOMMITTED and NOLOCK cannot be specified for tables modified by insert, update, or delete operations. The SQL Server query optimizer ignores the READUNCOMMITTED...

Thanks all.

Yeah, normally I too try to avoid loops, but in this case, it's probably better just to loop.

For absolute max efficiency, you can uncomment the UPDATE #bundles statement, although...

Yes, it works, it's easy enough to write code to prove it:

;with tbltest as (select cast('ab012' as varchar(5)) as TestNumber) select * from tblTest where TestNumber = cast(20012 as varchar(5))

Just...

READUNCOMMITTED and NOLOCK cannot be specified for tables modified by insert, update, or delete operations. The SQL Server query optimizer ignores the READUNCOMMITTED and NOLOCK...

But...

The biggest...

READUNCOMMITTED and NOLOCK cannot be specified for tables modified by insert, update, or delete operations. The SQL Server query optimizer ignores the READUNCOMMITTED and NOLOCK hints...

NOLOCK is NOT a bad thing when used properly, i.e., dirty reads are acceptable for that query (or you know that dirty reads aren't going to recur).  There has been...