Related to my prior question about having a sequence without interim holes (a guarantee that the numbers that are visible to readers are always incrementing) enter link description here I'd like to ask if a solution I devised makes sense.
I created a table with a
rowversion column. If I understand this correctly, SQL Server guarantees that the values will be always incrementing. Because this is just a bunch of bytes, queries like
WHERE RowVer > 1567 would requires a cast and hence would cause table scan.
So I created an index view that would do the cast and I am querying the view. On the surface level it works (the query plan shows index seek) but I am not sure if the <strong>always incrementing</strong> guarantee still holds true if I go through the index. Please help.
Edit It seems to work fine when debugging but inserting to my table block any selects against it. Need to investigate what kind of locks are being hold.
No, it doesn't make sense
rowversion/timestamp is <strong>database</strong> unique, not table unique. And it will be changed by UPDATEs to row(s), not just INSERTs. Therefore, this is not strictly monotonically increasing as you want.
Note that the number is not guaranteed to start at any particular value
Edit, what is "database unique"?
MSDN says for rowversion (timestamp)
Each database has a counter that is incremented for each insert or update operation that is performed on a table that contains a rowversion column within the database. This counter is the <strong>database rowversion</strong>
The current value is in