Sembra che la costante binaria 0xFFD8F...6DC0676 che hai usato per l'aggiornamento contiene un numero dispari di cifre esadecimali. E SqlServer ha aggiunto mezzo byte all'inizio del pattern in modo che rappresenti il numero intero di byte.
Puoi vedere lo stesso effetto eseguendo la seguente semplice query:
select 0x1, 0x104
Questo restituirà 0x01 e 0x0104 .
Il troncamento potrebbe essere dovuto ad alcune limitazioni in SSMS, che possono essere osservate nel seguente esperimento:
declare @b varbinary(max)
set @b = 0x123456789ABCDEF0
set @b = convert(varbinary(max), replicate(@b, 65536/datalength(@b)))
select datalength(@b) DataLength, @b Data
I risultati restituiti sono 65536 e 0x123456789ABCDEF0...EF0123456789ABCD , tuttavia, se in SSMS copio la colonna Dati, ottengo un pattern di 43677 caratteri (senza 0x iniziale), che è effettivamente 21838,5 byte. Quindi sembra che non dovresti (se lo fai) fare affidamento su valori di dati binari lunghi ottenuti tramite copia/incolla in SSMS.
L'alternativa affidabile può essere l'utilizzo della variabile intermedia:
declare @data varbinary(max)
select @data = DataXXX from Table_XXX where ID = XXX
update Table_YYY set DataYYY = @data where ID = YYY
