конвертиране на sql server rowversion в long или ulong?

Има значение. Искате вашето сравнение да има същия резултат като сравнението на SQL Server. SQL Server използва неподписани сравнения на двоични типове:

select case when 0x0FFFFFFFFFFFFFFF < 0xFFFFFFFFFFFFFFFF then 'unsigned' else 'signed' end

Ако направите същото с long който е подписан, 0xFFFFFFFFFFFFFFFF представлява -1 . Това означава, че вашето сравнение ще бъде неправилно; няма да съвпада със същото сравнение, направено в SQL Server.

Това, което определено искате, е да използвате ulong където 0xFFFFFFFFFFFFFFFF е ulong.MaxValue .

Endianness също е важен

Освен това, както Марк посочи, BitConverter.GetUInt64 не се конвертира правилно. Марк не е напълно прав - BitConverter е или big-endian, или little-endian в зависимост от системата, на която работи. Можете да вижте това сами . Също така, дори ако BitConverter винаги е бил little-endian, Array.Reverse е по-малко производителен с разпределение на купчина и копиране байт по байт. BitConverter просто не е семантично или практически правилният инструмент за работата.

Ето какво искате:

static ulong BigEndianToUInt64(byte[] bigEndianBinary)
{
    return ((ulong)bigEndianBinary[0] << 56) |
           ((ulong)bigEndianBinary[1] << 48) |
           ((ulong)bigEndianBinary[2] << 40) |
           ((ulong)bigEndianBinary[3] << 32) |
           ((ulong)bigEndianBinary[4] << 24) |
           ((ulong)bigEndianBinary[5] << 16) |
           ((ulong)bigEndianBinary[6] <<  8) |
                   bigEndianBinary[7];
}

Най-чистото решение

Актуализация :Ако използвате .NET Core 2.1 или по-нова версия (или .NET Standard 2.1), можете да използвате BinaryPrimitives.ReadUInt64BigEndian което пасва идеално.

В .NET Framework ето решението, което използвам:Timestamp.cs . По принцип, след като прехвърлите към Timestamp , не можете да сбъркате.