SQL Server RowVersion/Timestamp - Comparisons

48,801

Solution 1

From MSDN:

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. This tracks a relative time within a database, not an actual time that can be associated with a clock. Every time that a row with a rowversion column is modified or inserted, the incremented database rowversion value is inserted in the rowversion column.

http://msdn.microsoft.com/en-us/library/ms182776.aspx

  • As far as I understand, nothing ACTUALLY happens simultaneously in the system. This means that all rowversions should be unique. I venture to say that they would be effectively useless if duplicates were allowed within the same table. Also giving credance to rowversions not being duplicated is MSDN's stance on not using them as primary keys not because it would cause violations, but because it would cause foreign key issues.
  • According to MSDN, "The rowversion data type is just an incrementing number..." so yes, later is larger.

To the question of how much it increments, MSDN states, "[rowversion] tracks a relative time within a database" which indicates that it is not a fluid integer incrementing, but time based. However, this "time" reveals nothing of when exactly, but rather when in relation to other rows a row was inserted/modified.

Solution 2

Some additional information. RowVersion converts nicely to bigint and thus one can display better readable output when debugging:

CREATE TABLE [dbo].[T1](
    [Id] [int] IDENTITY(1,1) NOT NULL,
    [Value] [nvarchar](50) NULL,
    [RowVer] [timestamp] NOT NULL
) 

insert into t1 ([value]) values ('a')
insert into t1 ([value]) values ('b')
insert into t1 ([value]) values ('c')
select Id, Value,CONVERT(bigint,rowver)as RowVer from t1
update t1 set [value] = 'x' where id = 3
select Id, Value,CONVERT(bigint,rowver)as RowVer from t1
update t1 set [value] = 'y' 
select Id, Value,CONVERT(bigint,rowver)as RowVer from t1

Id  Value   RowVer
1   a   2037
2   b   2038
3   c   2039

Id  Value   RowVer
1   a   2037
2   b   2038
3   x   2040

Id  Value   RowVer
1   y   2041
2   y   2042
3   y   2043

Solution 3

I spent ages trying to sort something out with this - to ask for columns updated after a particular sequence number. The timestamp is really just a sequence number - it's also bigendian when c# functions like BitConverter.ToInt64 want littleendian.

I ended up creating a db view on the table i want data from with an alias column 'SequenceNo'

SELECT     ID, CONVERT(bigint, Timestamp) AS SequenceNo
FROM         dbo.[User]

c# Code first sees the view (ie UserV) identically to a normal table

then in my linq I can join the view and parent table and compare with a sequence number

var users =  (from u in context.GetTable<User>()
                join uv in context.GetTable<UserV>() on u.ID equals uv.ID
                where mysequenceNo < uv.SequenceNo
                orderby uv.SequenceNo
                select u).ToList();

to get what I want - all the entries changed since the last time I checked.

Solution 4

What makes you think Timestamp data types are evil? The data type is very useful for concurrency checking. Linq-To-SQL uses this data type for this very purpose.

The answers to your questions:

1) No. This value is updated each time the row is updated. If you are updating the row say five times, each update will increment the Timestamp value. Of course, you realize that updates that "occur simultaneously" really don't. They still only occur one at a time, in turn.

2) Yes.

Solution 5

Just as a note, timestamp is deprecated in SQL Server 2008 onwards. rowversion should be used instead.

From this page on MSDN:

The timestamp syntax is deprecated. This feature will be removed in a future version of Microsoft SQL Server. Avoid using this feature in new development work, and plan to modify applications that currently use this feature.

Share:
48,801
David Pfeffer
Author by

David Pfeffer

I'm the CTO of the startup company FunnelFire, where we build a sophisticated real-time sales intelligence platform. I'm also an adjunct professor of Computer Science at Stevens Institute of Technology, where I teach a variety of courses from Introduction to C++11, to Data Structure and Algorithms, to TCP/IP Networking (an advanced programming course where students re-implement the network stack). I graduated in 2009 from Stevens Institute of Technology with a bachelors and masters of science in Computer Science, a minor in Law &amp; Public Policy, and graduate certificates in Computer Systems, Databases &amp; Service Oriented Architecture, Distributed Systems, Enterprise Computing, Quantitative Software Engineering, and Service Oriented Computing. I got my start programming at a very young age, writing QBasic programs to display colorful circles on the screen while sitting on my dad's lap when I was 3 years old. My first big projects were a Super Mario World clone for GameBoy, a MUD called HybridMOO, and a home automation package called IntellHome (which I still use!). I'm actively involved in a number of open source initiatives, including an open-source middleware tool called PushoverQ. I am interested in hiking, exploration of abandoned or neglected sites and buildings, photography (particularly of those abandoned sites, but also glamour/editorial), cooking, snowshoeing, and New Jersey trivia/history.

Updated on May 31, 2020

Comments

  • David Pfeffer
    David Pfeffer about 4 years

    I know that the value itself for a RowVersion column is not in and of itself useful, except that it changes each time the row is updated. However, I was wondering if they are useful for relative (inequality) comparison.

    If I have a table with a RowVersion column, are either of the following true:

    • Will all updates that occur simultaneously (either same update statement or same transaction) have the same value in the RowVersion column?
    • If I do update "A", followed by update "B", will the rows involved in update "B" have a higher value than the rows involved in update "A"?

    Thanks.