Wygląda na to, że stała binarna 0xFFD8F...6DC0676 użyty do aktualizacji zawiera nieparzystą liczbę cyfr szesnastkowych. A SqlServer dodał pół bajtu na początku wzorca, aby reprezentował całą liczbę bajtów.
Możesz zobaczyć ten sam efekt, uruchamiając następujące proste zapytanie:
select 0x1, 0x104
To zwróci 0x01 i 0x0104 .
Obcięcie może wynikać z pewnych ograniczeń w SSMS, które można zaobserwować w następującym eksperymencie:
declare @b varbinary(max)
set @b = 0x123456789ABCDEF0
set @b = convert(varbinary(max), replicate(@b, 65536/datalength(@b)))
select datalength(@b) DataLength, @b Data
Zwracane wyniki to 65536 i 0x123456789ABCDEF0...EF0123456789ABCD , jednak jeśli w SSMS skopiuję kolumnę Data otrzymuję wzorzec o długości 43677 znaków (bez wiodącego 0x), czyli efektywnie 21838,5 bajtów. Wygląda więc na to, że nie powinieneś (jeśli tak) polegać na długich wartościach danych binarnych uzyskanych poprzez kopiowanie/wklejanie w SSMS.
Niezawodną alternatywą może być użycie zmiennej pośredniej:
declare @data varbinary(max)
select @data = DataXXX from Table_XXX where ID = XXX
update Table_YYY set DataYYY = @data where ID = YYY
