最近我想做一些数据修补，并尝试更新varbinary(MAX)类型的列，更新值如下：
0xFFD8F。。。6DC0676
但是，在更新查询成功运行后，值变为：
0x0FFD8…6DC067
最后4位似乎丢失了，或者整个值右移了一个字节。。。
我尝试删除整行并运行插入查询，同样的事情也发生了！
有人能告诉我为什么会发生这种事吗；我该怎么解决？谢谢
我已经尝试了几种不同长度的二进制，以获得最大值43658个字符(每个代表4位，总计约21KB)，更新查询正常运行。多出1个字符会使上面的"bug"出现。。。
PS1：对于较短长度的varbinary作为更新值，一切正常
PS2：如果有帮助的话，我可以发布整个二进制字符串，但它真的很长，我不确定是否适合在这里发布
编辑：感谢您的帮助！
正如有人建议的那样，插入的值可能是奇数的4位，所以前面有一个0附加。以下是我关于该值的更新信息：
该值为43677个字符长，不包括"0x"，这意味着是的，它是奇数
它确实解释了之前插入"0"的原因，但并没有解释最后一个字符消失的原因
然后我做了一个实验：
我插入一个偶数长度值，并在原始值前手动添加一个"0">，
现在要更新的值是
0x0FFD8F。。。6DC0676
，长度43678个字符，不包括"0x">
结果没有运气，更新后的值仍然是
0x0FFD8…6DC067
用于更新的二进制常量0xFFD8F...6DC0676似乎包含奇数个十六进制数字。SqlServer在模式的开头添加了半个字节，这样它就代表了整个字节数。
运行以下简单查询可以看到相同的效果：
select 0x1, 0x104
这将返回0x01和0x0104。
截断可能是由于SSMS中的一些限制，可以在以下实验中观察到：
declare @b varbinary(max)
set @b = 0x123456789ABCDEF0
set @b = convert(varbinary(max), replicate(@b, 65536/datalength(@b)))
select datalength(@b) DataLength, @b Data
返回的结果是65536和0x123456789ABCDEF0...EF0123456789ABCD，但是，如果在SSMS I copy Data列中，我得到的模式长度为43677个字符(没有前导0x)，有效地为21838.5个字节。因此，您似乎不应该(如果您这样做的话)依赖于通过在SSMS中复制/粘贴获得的长二进制数据值。
可靠的替代方案可以使用中间变量：
declare @data varbinary(max)
select @data = DataXXX from Table_XXX where ID = XXX
update Table_YYY set DataYYY = @data where ID = YYY