<p>Assuming a Read Committed Snapshot transaction isolation setting, is the following statement "atomic" in the sense that you won't ever "lose" a concurrent increment?</p>

<pre><code>update mytable set counter = counter + 1
</code></pre>

<p>I would assume that in the general case, where this update statement is part of a larger transaction, that it wouldn't be. For example, I think this scenario is possible:</p>

<ul>
<li>update the counter within transaction #1</li>
<li>do some other stuff
in transaction #1</li>
<li>update the counter
with transaction #2</li>
<li>commit
transaction #2</li>
<li>commit transaction #1</li>
</ul>

<p>In this situation, wouldn't the counter end up only being incremented by 1? Does it make a difference if that is the only statement in a transaction?</p>

<p>How does a site like stackoverflow handle this for its question view counter? Or is the possibility of "losing" some increments just considered acceptable?</p>

No, it's not. The value is read in shared mode and then updated in exclusive mode, so multiple reads can occur.
Either use Serializable level or use something like
```
```
update t
set counter = counter+1
from t with(updlock, <some other hints maybe>)
where foo = bar
```
```