Parece que la constante binaria 0xFFD8F...6DC0676 que usó para la actualización contiene un número impar de dígitos hexadecimales. Y SqlServer agregó medio byte al comienzo del patrón para que represente un número entero de bytes.
Puede ver el mismo efecto ejecutando la siguiente consulta simple:
select 0x1, 0x104
Esto devolverá 0x01 y 0x0104 .
El truncamiento puede deberse a algunas limitaciones en SSMS, que se pueden observar en el siguiente experimento:
declare @b varbinary(max)
set @b = 0x123456789ABCDEF0
set @b = convert(varbinary(max), replicate(@b, 65536/datalength(@b)))
select datalength(@b) DataLength, @b Data
Los resultados devueltos son 65536 y 0x123456789ABCDEF0...EF0123456789ABCD , sin embargo, si en SSMS copio la columna de datos, obtengo un patrón de 43677 caracteres de longitud (sin 0x inicial), que es 21838,5 bytes de manera efectiva. Por lo tanto, parece que no debe confiar (si lo hace) en valores de datos binarios largos obtenidos mediante copiar/pegar en SSMS.
La alternativa confiable puede ser usar una variable intermedia:
declare @data varbinary(max)
select @data = DataXXX from Table_XXX where ID = XXX
update Table_YYY set DataYYY = @data where ID = YYY
