表中数据类型rowversion的使用是否始终可靠？
我在将值与此数据类型的列（即select * from MyTable where tStamp > @value）进行比较时遇到了问题，并且在调查此问题时 - 我发现了一些奇怪的结果。我不确定这是我的误解，还是更大的问题，这意味着无法依赖数据类型。
在数据库中是一个表（MyTable），tStamp列是rowversion数据类型，其中最小值为0x00000004355B68B7。有一个存储过程接受类型为rowversion的参数作为输入，但它又调用使用数据类型binary(8)的输入参数的过程。所以第一个过程被声明为
create procedure proc1 @inputTS rowversion
，第二个声明为
create procedure proc2 @inputTS binary(8)
我最初假设我遇到的问题是由于数据类型不同（当proc1调用proc2时它将值@InputTS传递给它）。当我将proc2改为使用rowversion时，我得到了预期的结果。但后来我尝试了一些测试，我从那些测试中看到的......很奇怪。
如果我使用值0x0000000070000000：
declare @testRV rowversion = 0x0000000070000000
declare @testBin binary(8) = @testRV
select * from MyTable where tStamp > @testRV -- First Query
select * from MyTable where tStamp > @testBin -- Second Query
我发现第一个选择没有返回任何行，第二个返回所有行。他们都应该返回所有行。如果我将值更改为0x000000006FFFFFFF或0x0000000070000001，则两个查询都会返回所有行。
如果我使用值0x0000000080000000，则两个查询都不返回任何行。使用此值 - 0x0000000441CED675 - 两个都返回了行，但是这个值 - 0x0000000481CED675 - 都没有返回行。然后使用此值 - 0x0000000080000001 - 第一个查询返回所有行，第二个返回无
有一次我在想，在内部，SQL将值视为2个整数 - 即0x0000000080000000是0x00000000和0x80000000。由于这是一个高于最大int大小并被视为-2147483648，看起来问题是“较低”整数被视为负数。但这并不能解释使用0x0000000070000000或0x0000000080000001时的行为。
我在2008 R2到2017的SQL Server版本上试过这个，每次都得到相同的结果。
我是否遗漏了有关如何使用rowversion的内容？