The data still has to be read -- how else would SQL know that the proposed new value was the same as the value in the table itself?

It's...

Paul is certainly a worthwhile authority.   I will study his article later.   I did notice this quote, which was emphasized:

A clustered table will always produce full logging and dirty buffer...

Same result.    Identical timings and statistics.    Potential update to a unique clustered index column does cause additional I/O, but it's because the query plan has to include a...

Scott, could you please cite some authority to that effect?     I couldn't find it with some quick googling, so I ran an experiment.    The code below is showing...

ZZartin is right.    It's not only easier to code, it's faster when executing.

INSERT INTO TargetTable (ColX, ColY, ColZ)
SELECT ColA, ColB, ColC
FROM SourceTable
WHERE ...

Plenty of examples are...

"I guess it takes the HASH directive into account for the whole query, not just the one JOIN where it is specified."

When you force the HASH join on one table,...

I would not get into the habit of using OR to test variable values when trying to add flexibility to queries like this.   For one thing, you get a single...

Yes.    Eirikur's version of DelimitedSplit8k is fast AND is an inline table valued function.   Everyone who can't use String_Split should get a copy.   Also, use of an inline table-valued...

Looking at the two plans, it seems that the TOP 1 version tries to avoid the sort.   (With disastrous results.)    Apparently it can read the correct sequence from the...

You are absolutely correct, Jeff.

select conta, descritivo, edeb
,RunningTotal = SUM(edeb) OVER(PARTITION BY conta ORDER BY dinome, NrLanc ROWS UNBOUNDED PRECEDING)
from  #tmpTable
order by conta, dinome, NrLanc

I would do this with dynamic SQL.   Build the basic query string and then add the WHERE clause only when both date parameters are null.    Using sp_ExecuteSQL allows you...

What if one of the date parameters is populated but the other isn't?

Here is a quick example of using SUM() with an OVER clause to create a running total without having to UPDATE.  It uses the data from your #tmpTable.

            
April 12, 2021 at 3:39 pm
            
#3870171

            
            
                                                
        

Good catch, Scott.   I wasn't thinking about his use of a LEFT Join.

You could also do it with a cross applied subquery.     Whether or not it this a "better" way usually means which runs faster.     Performance will depend on the...