Het lijkt erop dat de binaire constante 0xFFD8F...6DC0676 die u voor de update hebt gebruikt, bevat een oneven aantal hexadecimale cijfers. En de SqlServer voegde een halve byte toe aan het begin van het patroon, zodat het een geheel aantal bytes vertegenwoordigt.
U kunt hetzelfde effect zien als u de volgende eenvoudige zoekopdracht uitvoert:
select 0x1, 0x104
Dit retourneert 0x01 en 0x0104 .
De afknotting kan te wijten zijn aan enkele beperkingen in SSMS, die kunnen worden waargenomen in het volgende experiment:
declare @b varbinary(max)
set @b = 0x123456789ABCDEF0
set @b = convert(varbinary(max), replicate(@b, 65536/datalength(@b)))
select datalength(@b) DataLength, @b Data
De geretourneerde resultaten zijn 65536 en 0x123456789ABCDEF0...EF0123456789ABCD , maar als ik in SSMS de kolom Gegevens kopieer, krijg ik een patroon van 43677 tekens lang (dit is zonder 0x te leiden), wat effectief 21838.5 bytes is. Het lijkt er dus op dat u niet (als u dat doet) moet vertrouwen op lange binaire gegevenswaarden die zijn verkregen via kopiëren/plakken in SSMS.
Het betrouwbare alternatief kan het gebruik van een tussenvariabele zijn:
declare @data varbinary(max)
select @data = DataXXX from Table_XXX where ID = XXX
update Table_YYY set DataYYY = @data where ID = YYY