Consequences of Indexing the rowversion/timestamp

Question

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 always incrementing 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.

Answer 1

No, it doesn't make sense

rowversion/timestamp is database 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 database rowversion

The current value is in @@DBTS