Det ser ud til, at den binære konstant 0xFFD8F...6DC0676 som du brugte til opdateringen indeholder et ulige antal hex-cifre. Og SQLServeren tilføjede halvbyte i begyndelsen af mønsteret, så det repræsenterer hele antallet af bytes.
Du kan se den samme effekt ved at køre følgende simple forespørgsel:
select 0x1, 0x104
Dette vil returnere 0x01 og 0x0104 .
Trunkeringen kan skyldes nogle begrænsninger i SSMS, som kan observeres i følgende eksperiment:
declare @b varbinary(max)
set @b = 0x123456789ABCDEF0
set @b = convert(varbinary(max), replicate(@b, 65536/datalength(@b)))
select datalength(@b) DataLength, @b Data
De returnerede resultater er 65536 og 0x123456789ABCDEF0...EF0123456789ABCD Men hvis jeg kopierer datakolonnen i SSMS, får jeg et mønster på 43677 tegn (dette er uden foranstående 0x), hvilket er 21838,5 bytes effektivt. Så det ser ud til, at du ikke (hvis du gør det) bør stole på lange binære dataværdier opnået via copy/paste i SSMS.
Det pålidelige alternativ kan være at bruge mellemvariabel:
declare @data varbinary(max)
select @data = DataXXX from Table_XXX where ID = XXX
update Table_YYY set DataYYY = @data where ID = YYY