Zdá se, že binární konstanta 0xFFD8F...6DC0676 který jste použili pro aktualizaci obsahuje lichý počet hexadecimálních číslic. A SqlServer přidal půl bajtu na začátek vzoru, takže reprezentoval celý počet bajtů.
Stejný efekt můžete vidět při spuštění následujícího jednoduchého dotazu:
select 0x1, 0x104
To vrátí 0x01 a 0x0104 .
Zkrácení může být způsobeno určitými omezeními v SSMS, které lze pozorovat v následujícím experimentu:
declare @b varbinary(max)
set @b = 0x123456789ABCDEF0
set @b = convert(varbinary(max), replicate(@b, 65536/datalength(@b)))
select datalength(@b) DataLength, @b Data
Vrácené výsledky jsou 65536 a 0x123456789ABCDEF0...EF0123456789ABCD , nicméně pokud v SSMS zkopíruji sloupec Data, dostávám vzor o délce 43677 znaků (toto je bez úvodní 0x), což je efektivně 21838,5 bajtů. Zdá se tedy, že byste se neměli (pokud ano) spoléhat na dlouhé binární hodnoty dat získané pomocí kopírování/vkládání v SSMS.
Spolehlivou alternativou může být použití meziproměnné:
declare @data varbinary(max)
select @data = DataXXX from Table_XXX where ID = XXX
update Table_YYY set DataYYY = @data where ID = YYY