Sql server SQL Server blob损坏

我们有一个系统，将timeseries数据存储在SQLServer2008R2的BLOB字段中

该表如下所示（简化，跳过某些列）：

我有一个python进程，可以连续地追加“data”并增加“Count”。 一个不变量是

len（data）==4*Count

应始终保持不变。我在代码中有一个不变量作为断言。偶尔（每隔两个月左右），此断言会失败—其中

len（数据）

将比预期值少一个字节

为了“修复”数据并让我的进程在不违反断言的情况下继续，我尝试附加一个零字节。但这会使水滴的长度增加两倍

以下是我所做工作的细节：

select TSMode, 4*count as count4, len(data) as len 
from T_TimeSeries where Tag='<tag-of-the-affected-row>'

然后我附加零字节，如下所示：

update T_TimeSeries set data.Write(0x00, NULL, 0) where Tag='<tag-of-the-affected-row>'

这不是SQL Server中存在缺陷的明显证据吗？我附加一个字节，长度从233775跳到233777。 我可以不断地重复它-用data.write（0x，233776，1）删除一个字节以返回到长度233775

我的过程的正常数据写入模式并不总是线性的，有时我们插入中间，替换现有的数据。但无论我们执行什么步骤，我都认为我们永远不应该陷入这种状态——在我看来，这就像是数据库崩溃

你同意吗

---

我想知道这是否真的是一个SQL Server错误，或者我做错了什么，因为这将决定我们应该如何修复这种情况：-）

LEN

将

varbinary

转换为

varchar

，并测量字符串长度。这排除了可能导致差异的因素。在二进制文件末尾添加一个零字节将使其长度增加尾随空格数加上一

---

所以这不是一个bug。正如Dan指出的，使用

DATALENGTH

LEN

将

varbinary

转换为

varchar

并测量字符串长度。这排除了可能导致差异的因素。在二进制文件末尾添加一个零字节将使其长度增加尾随空格数加上一

---

所以这不是一个bug。正如Dan指出的，使用

DATALENGTH

LEN

将

varbinary

转换为

varchar

并测量字符串长度。这排除了可能导致差异的因素。在二进制文件末尾添加一个零字节将使其长度增加尾随空格数加上一

---

所以这不是一个bug。正如Dan指出的，使用

DATALENGTH

LEN

将

varbinary

转换为

varchar

并测量字符串长度。这排除了可能导致差异的因素。在二进制文件末尾添加一个零字节将使其长度增加尾随空格数加上一

---

所以这不是一个bug。正如Dan指出的，使用

DATALENGTH

如果使用

DATALENGTH

函数而不是

LEN

计算长度会发生什么？哦，DATALENGTH生成预期结果：233776。如果使用

DATALENGTH

函数而不是

LEN

计算长度，会发生什么情况？哦，DATALENGTH生成预期结果：233776。如果使用

DATALENGTH

函数而不是

LEN

计算长度，会发生什么情况？哦，DATALENGTH生成预期结果：233776。如果使用

DATALENGTH

函数而不是

LEN

计算长度，会发生什么情况？哦，DATALENGTH生成预期结果：233776。谢谢，丹。谢谢，蒂姆。：-）我很少看到违反断言的情况。也许这是因为我的blob是ieeefloat32数组的直接内存拷贝，小endian。似乎这种编码很少以0x20Yes结束，在小端编码中，最后一个字节覆盖IEEE float32指数。本例中的编码编号约为3e-19。只有大约这个数量级的数字才会在编码中有最后的0x20字节，从而导致LEN给我错误的字节计数。谢谢，Dan。谢谢，蒂姆。：-）我很少看到违反断言的情况。也许这是因为我的blob是ieeefloat32数组的直接内存拷贝，小endian。似乎这种编码很少以0x20Yes结束，在小端编码中，最后一个字节覆盖IEEE float32指数。本例中的编码编号约为3e-19。只有大约这个数量级的数字才会在编码中有最后的0x20字节，从而导致LEN给我错误的字节计数。谢谢，Dan。谢谢，蒂姆。：-）我很少看到违反断言的情况。也许这是因为我的blob是ieeefloat32数组的直接内存拷贝，小endian。似乎这种编码很少以0x20Yes结束，在小端编码中，最后一个字节覆盖IEEE float32指数。本例中的编码编号约为3e-19。只有大约这个数量级的数字才会在编码中有最后的0x20字节，从而导致LEN给我错误的字节计数。谢谢，Dan。谢谢，蒂姆。：-）我很少看到违反断言的情况。也许这是因为我的blob是ieeefloat32数组的直接内存拷贝，小endian。似乎这种编码很少以0x20Yes结束，在小端编码中，最后一个字节覆盖IEEE float32指数。本例中的编码编号约为3e-19。只有大约这个数量级的数字才会在编码中有最后的0x20字节，从而导致LEN给我错误的字节计数。

count4  len
233776  233775

update T_TimeSeries set data.Write(0x00, NULL, 0) where Tag='<tag-of-the-affected-row>'

count4  len
233776  233777