ODBC原生客户端获取SQL Server DateTime2字段时毫秒舍入问题解析

开发者阿泽

2026-10-31

场景说明

需要通过ODBC原生客户端读取SQL Server中DateTime2类型字段的值，对应的数据表结构定义如下：

CREATE TABLE [dbo].[MyTable](
    [tagname] [nvarchar(30)] NOT NULL,
    [date] [datetime2] NOT NULL
)

现有实现

C++客户端读取date字段的逻辑如下：

TIMESTAMP_STRUCT ts;
SQLLEN cbhiredate;
if (!SQL_SUCCEEDED(SQLGetData(hStmt, 2, SQL_C_TIMESTAMP, &ts, sizeof(TIMESTAMP_STRUCT), &cbhiredate)))

异常现象

上述代码在多数场景下运行正常，但部分读取结果会出现毫秒值的异常舍入：

复现样例：SQL Server中存储的原始日期值为2020/01/11 17:15:38.6850000，经代码读取后，客户端获取到的日期值变为2020/01/11 17:15:38.686
运行环境：数据库版本为SQL Server 2012 SP4
待确认问题：当前字段获取的实现代码是否存在缺陷，以及异常舍入现象的产生原因

异常产生的原因

核心问题是选择的绑定类型与驱动实现逻辑不匹配
- 代码中用于SQLGetData的目标类型SQL_C_TIMESTAMP是ODBC 2.x时代的兼容类型，原生精度仅对应SQL Server老版datetime字段（实际精度约3.33毫秒），并非为高精度的datetime2类型设计。
- SQL Server 2012 SP4配套的SQL Server Native Client 11.0驱动，在将datetime2字段值转换为旧版兼容时间类型时，存在已知的单位映射缺陷：驱动内部会把源端的纳秒级精度值做错误的单位缩放，再按照四舍五入规则截断到目标类型的低精度，最终导致你观察到的非预期舍入。
- 你遇到的复现场景中，数据库存储的原始值小数部分为685000000纳秒（即685毫秒），驱动在转换时错误将纳秒值按微秒粒度做计算，在精度截断环节触发四舍五入，最终输出了686毫秒的偏差结果。
补充说明：TIMESTAMP_STRUCT结构体的纳秒级精度定义是ODBC 3.8规范才新增的，旧驱动对老版本兼容类型的转换逻辑，不会主动适配datetime2的高精度映射规则。

优先将绑定类型替换为SQL_C_TYPE_TIMESTAMP，这是ODBC 3.8规范中专门对应高精度时间戳的类型，驱动处理该类型时会严格按照纳秒单位映射datetime2的精度，完全规避错误缩放和非预期舍入。修改后的核心代码如下：
```
TIMESTAMP_STRUCT ts;
SQLLEN cbhiredate;
// 将原SQL_C_TIMESTAMP替换为SQL_C_TYPE_TIMESTAMP
if (!SQL_SUCCEEDED(SQLGetData(hStmt, 2, SQL_C_TYPE_TIMESTAMP, &ts, sizeof(TIMESTAMP_STRUCT), &cbhiredate)))
```
如果存在极旧版本驱动的兼容需求，可以改用SQL_C_BINARY类型直接读取datetime2字段的原生二进制值，按照SQL Server公开的datetime2二进制结构自行解析，可彻底绕开驱动层的转换逻辑缺陷。
注意事项：不要使用SQL_C_DATETIME、旧版SQL_C_TIMESTAMP这类低精度兼容类型读取datetime2字段，这类类型原生精度仅匹配老版datetime的3.33毫秒粒度，读取datetime2时必然会出现舍入偏差。

内容的提问来源于stack exchange，提问作者Khalid