Il semble que la constante binaire 0xFFD8F...6DC0676 que vous avez utilisé pour la mise à jour contient un nombre impair de chiffres hexadécimaux. Et le SqlServer a ajouté un demi-octet au début du modèle afin qu'il représente le nombre entier d'octets.
Vous pouvez voir le même effet en exécutant la simple requête suivante :
select 0x1, 0x104
Cela renverra 0x01 et 0x0104 .
La troncature peut être due à certaines limitations de SSMS, qui peuvent être observées dans l'expérience suivante :
declare @b varbinary(max)
set @b = 0x123456789ABCDEF0
set @b = convert(varbinary(max), replicate(@b, 65536/datalength(@b)))
select datalength(@b) DataLength, @b Data
Les résultats renvoyés sont 65536 et 0x123456789ABCDEF0...EF0123456789ABCD , cependant, si dans SSMS je copie la colonne de données, j'obtiens un modèle de 43677 caractères (c'est sans 0x en tête), soit 21838,5 octets effectivement. Il semble donc que vous ne devriez pas (si vous le faites) compter sur de longues valeurs de données binaires obtenues par copier/coller dans SSMS.
L'alternative fiable peut être d'utiliser une variable intermédiaire :
declare @data varbinary(max)
select @data = DataXXX from Table_XXX where ID = XXX
update Table_YYY set DataYYY = @data where ID = YYY
