Posted by jpluimers on 2021/05/18
A while ago, I needed to get RowVersion binary data out of SQL Server. People around me told me it is stored as BigInt.
I luckily bumped into [WayBack] sql server – Cast rowversion to bigint – Stack Overflow.
That post explains RowVersion is not stored as BigInt. Both RowVersion and BigInt take up 8 bytes of storage, but RowVersion is big-endian and unsigned, whereas BigInt is little-endian and signed.
A few quotes from it:
In my C# program I don’t want to work with byte array, therefore I cast rowversion data type to bigint:
SELECT CAST([version] AS BIGINT) FROM [dbo].[mytable]So I receive a number instead of byte array. Is this conversion always successful and are there any possible problems with it? If so, in which data type should I cast rowversion instead?
and
You can convert in C# also, but if you want to compare them you should be aware that rowversion is apparently stored big-endian, so you need to do something like:
byte[] timestampByteArray = ... // from datareader/linq2sql etc... var timestampInt = BitConverter.ToInt64(timestampByteArray, 0); timestampInt = IPAddress.NetworkToHostOrder(timestampInt);It’d probably be more correct to convert it as ToUInt64, but then you’d have to write your own endian conversion as there’s no overload on NetworkToHostOrder that takes uint64. Or just borrow one from Jon Skeet (search page for ‘endian’).
Code: [WayBack] Jon Skeet: Miscellaneous Utility Library
Related:
The Intel x86 and also AMD64 / x86-64 series of processors use the little-endian format, and for this reason, it is also known in the industry as the “Intel convention“.
Endianness is also important
Additionally, as Mark pointed out,
BitConverter.GetUInt64is not converting properly. Mark is not completely right–BitConverteris either big-endian or little-endian depending on the system it’s running on.
–jeroen
The Wiert Corner - irregular stream of stuff 
Leave a comment