Casting de varbinary
a bigint
(y viceversa) utiliza el orden de bytes de la red (big-endian). BitConverter
usa el endian-ness de la máquina en la que se ejecuta (little-endian para x86 y x64).
Por lo tanto BitConverter.GetBytes
corrida en -8588797048854775808 (0x88CE7696E7167800) es {0x00,0x88,0xE9,0x18,0x69,0x89,0x31,0x77}, y cast
en {0x00,0x88,0xE9,0x18,0x69,0x89,0x31, 0x77} es 0x0088E91869893177 = 38536887891734903.
Lo más obvio es almacenar números enteros de 64 bits como enteros de 64 bits en primer lugar.
Si realmente necesita hacer esta conversión a continuación:
var savedValue = BitConverter.GetBytes(IPAddress.HostToNetworkOrder(longValue))
intercambiará alrededor de los bytes, además de ser portátil en el que no va a cambiar los bytes si se ejecuta en una máquina-big endian.
Como alternativa, si no desea utilizar el espacio de nombres System.Net por alguna razón, o si desea ser extensible a otros tipos de los tres IPAddress.HostToNetworkOrder
handeles, utilice:
var savedValue = BitConverter.GetBytes(longValue);
if(BitConverter.IsLittleEndian)
Array.Reverse(savedValue);
¿por qué guardar un entero de 64 bits como varbinary en primer lugar? – BrokenGlass
Normalmente, almacenaría 'long' en C# como' bigint' en SQL Server. ¿Hay alguna razón particular por la que intentas almacenar 'long' como' varbinary'? – rsbarro
Porque ese campo DB no contiene solo valores de tipo int64. – Maybe