title: Is @@ROWCOUNT after UPDATE reliably a measure of *matching* rows?
body: <p>Does <code>@@ROWCOUNT</code> reliably tell you how many rows <em>matched</em> the <code>WHERE</code> clause in an <code>UPDATE</code>, as opposed to how many where actually <em>changed</em> by it?</p>
  <p>In <a href="http://msdn.microsoft.com/en-gb/library/ms187316.aspx" rel="nofollow noreferrer">the documentation for <code>@@ROWCOUNT</code></a> it says:</p>
  <blockquote>
  <p>Data manipulation language (DML) statements set the <code>@@ROWCOUNT</code> value to the number of rows <strong>affected</strong> by the query and return that value to the client.</p>
  </blockquote>
  <p><em>(My emphasis.)</em></p>
  <p>But if I have</p>
  <pre><code>CREATE TABLE [Foo] ([a] INT, [b] INT)
  GO
  INSERT INTO [Foo] ([a], [b]) VALUES (1, 1),(1, 2),(1, 3),(2, 2)
  GO
  UPDATE [Foo] SET [b] = 1 WHERE [a] = 1
  SELECT @@ROWCOUNT
  GO
  </code></pre>
  <p>...I see <code>3</code> (the number of rows matching <code>[a] = 1</code>), not <code>2</code> (the number of rows modified by the <code>UPDATE</code> — one of the three rows already had the value <code>1</code> for <code>b</code>). This seems like an odd definition of &quot;affected&quot; (not <em>wrong</em>, just at odds with how I'd normally use the word — it's actually quite handy for what I want to do, in fact).</p>
  <p>(The similar MySQL <a href="http://dev.mysql.com/doc/refman/5.7/en/information-functions.html#function_row-count" rel="nofollow noreferrer"><code>ROW_COUNT</code></a> function, for instance, would return <code>2</code> in this situation.)</p>
  <p>Is this reliable behavior, ideally documented somewhere I just haven't found? Or are there odd edge cases...</p>
  <p><strong>To be clear:</strong> I'm not asking if <code>3</code> is the <em>right</em> answer. I'm asking if it's a <strong>reliable</strong> answer, or are there edge cases where SQL Server will leave out rows that matched but didn't require a change.</p>
  <p><strong>Update</strong>: A couple of people have asked (or hinted at) what kind of &quot;reliability&quot; issues I'm worried about. The fact is they're quite nebulous, but, I don't know, replication? Transactions? Partitioning? Indexes it could use to avoid seeking to rows because it knows that <code>b</code> is already <code>1</code>, and so it skips those? ...?</p>
  <p><strong>Update</strong>: I was hoping for someone with a more &quot;insider&quot; view of how SQL Server works to answer this question, but it looks like the triggers example (and others I've played with) <a href="https://stackoverflow.com/a/23954719/157247">by xacinay</a> is as close as we're going to get. And it seems pretty darned solid; if it behaves that way in the normal case and it didn't behave that way despite partitioning or whatsit, as someone said, surely that would qualify as a bug. It's just empirical rather than academic.</p>