Det verkar som om den binära konstanten 0xFFD8F...6DC0676
som du använde för uppdateringen innehåller udda antal hexadecimala siffror. Och SQLServer lade till halvbyte i början av mönstret så att den representerar ett helt antal byte.
Du kan se samma effekt när du kör följande enkla fråga:
select 0x1, 0x104
Detta returnerar 0x01
och 0x0104
.
Trunkeringen kan bero på vissa begränsningar i SSMS, som kan observeras i följande experiment:
declare @b varbinary(max)
set @b = 0x123456789ABCDEF0
set @b = convert(varbinary(max), replicate(@b, 65536/datalength(@b)))
select datalength(@b) DataLength, @b Data
Resultaten som returneras är 65536
och 0x123456789ABCDEF0...EF0123456789ABCD
, men om jag kopierar datakolumnen i SSMS får jag ett mönster på 43677 tecken (detta är utan inledande 0x), vilket är 21838,5 byte i praktiken. Så det verkar som om du inte bör (om du gör det) lita på långa binära datavärden som erhålls via kopiera/klistra in i SSMS.
Det tillförlitliga alternativet kan vara att använda mellanliggande variabel:
declare @data varbinary(max)
select @data = DataXXX from Table_XXX where ID = XXX
update Table_YYY set DataYYY = @data where ID = YYY