Best alternative for rowversion

Question

We're currently evaluating SQL Server 2014's In-Memory OLTP for our application and saw in the documentation that rowversion is not a supported datatype: http://msdn.microsoft.com/en-us/library/dn133179(v=sql.120).aspx
What's regarded as best practice if we basically want to have the same functionality as rowversion in In-Memory OLTP? Using triggers would be a massive performance decrease for us compared to rowversion.

Answer 1

rowversion isn't a hash,  it's a database-wide durably-monotonically-increasing 8-byte binary value.  So the best way to get similar behavior is to implement your own database-wide durably-monotonically-increasing 8-byte value.
You can do this with a SEQUENCE object. eg
create sequence ts_seq as bigint start with 10000000
This is the same way you generate key values for memory tables, with the difference that this sequence is used to generate timestamp values for multiple tables, instead of key values for a single table.  You can then cast the value to binary(8) or store
it as bigint, as the sort orders are compatible, ie
for bigint a,b   a<b iff cast(a as bigint) < cast(b as bigint)
You can't access the sequence in a native proc, so you'll have to pass it in.  Eg here's how to fill up a memory table variable with sequence values (remember when NEXT VALUE FOR appears in a SELECT you get a new sequence value for each row of the output):
DECLARE @od Sales.SalesOrderDetailType_inmem
SET @DueDate = DATEADD(d, (@i % 10) + 2, @now)
DELETE FROM @od
INSERT @od
SELECT OrderQty, ProductID, SpecialOfferID, LocalID, (next value for ts_seq)
FROM Demo.DemoSalesOrderDetailSeed
WHERE OrderID = @i % @max_OrderID
Of course you must remember to get a new "timestamp" in any operation that inserts or updates the table.
David
David http://blogs.msdn.com/b/dbrowne/