从 SQL Server 2005 Native Client 更新应用程序
适用于:SQL Server Azure SQL 数据库 Azure SQL 托管实例 Azure Synapse Analytics Analytics Platform System (PDW)
重要
SQL Server Native Client (SNAC) 未随附:
- SQL Server 2022 (16.x) 及更高版本
- SQL Server Management Studio 19 及更高版本
不建议使用 SQL Server Native Client(SQLNCLI 或 SQLNCLI11)和旧的 Microsoft OLE DB Provider for SQL Server (SQLOLEDB)进行新的应用程序开发。
对于新项目,请使用以下驱动程序之一:
对于作为 SQL Server 数据库引擎组件(版本 2012 到 2019)随附的 SQLNCLI,请参阅此支持生命周期特例。
本主题讨论自 SQL Server 2005 中的 SQL Server Native Client(9.x)以来 SQL Server Native Client 中的中断性变更。
从Microsoft数据访问组件(MDAC)升级到 SQL Server Native Client 时,也可能看到一些行为差异。 有关详细信息,请参阅 从 MDAC 将应用程序更新到 SQL Server Native Client。
SQL Server Native Client 9.0 随 SQL Server 2005 (9.x) 附带。 SQL Server Native Client 10.0 随 SQL Server 2008 (10.0.x) 一起提供。 SQL Server Native Client 10.5 随 SQL Server 2008 R2 (10.50.x) 一起提供。 SQL Server Native Client 11.0 随 SQL Server 2012 (11.x) 和 SQL Server 2014 (12.x) 附带。
自 SQL Server 2005(9.x) 以来 SQL Server Native Client 中的更改行为 | 说明 |
---|---|
OLE DB 仅填充到定义的小数位数。 | 对于将数据发送到服务器的转换,SQL Server Native Client(从 SQL Server 2008 (10.0.x)开始)仅填充数据中尾随零,直到日期/时间值的最大长度。 SQL Server Native Client 9.0 则填充到 9 位数。 |
验证 ICommandWithParameter::SetParameterInfo 的 DBTYPE_DBTIMESTAMP。 | SQL Server Native Client(从 SQL Server 2008 (10.0.x)开始,实现 ICommandWithParameter::SetParameterInfo 中 bScale 的 OLE DB 要求,设置为DBTYPE_DBTIMESTAMP的小数秒精度。 |
sp_columns 存储过程现在返回“否” ,而不是为 IS_NULLABLE 列返回“否” 。 | 从 SQL Server Native Client 10.0(SQL Server 2008 (10.0.x)开始,sp_columns存储过程现在返回“NO”,而不是IS_NULLABLE列的“NO”。 |
SQLSetDescRec、SQLBindParameter 和 SQLBindCol 现在执行一致性检查。 | 在 SQL Server Native Client 10.0 之前,设置SQL_DESC_DATA_PTR不会导致对 SQLSetDescRec、SQLBindParameter 或 SQLBindCol 中的任何描述符类型进行一致性检查。 |
SQLCopyDesc 现在执行描述符一致性检查。 | 在 SQL Server Native Client 10.0 之前,SQLCopyDesc 在特定记录上设置SQL_DESC_DATA_PTR字段时没有执行一致性检查。 |
SQLGetDescRec 不再执行描述符一致性检查。 | 在 SQL Server Native Client 10.0 之前,SQLGetDescRec 在设置SQL_DESC_DATA_PTR字段时执行描述符一致性检查。 ODBC 规范和 SQL Server Native Client 10.0(SQL Server 2008(10.0.x)及更高版本中不需要这样做,此一致性检查不再执行。 |
日期超出范围时返回其他错误。 | 对于日期/时间类型,SQL Server Native Client(从 SQL Server 2008 (10.0.x 开始)将返回一个不同的错误号,表示超出范围的日期,而不是在早期版本中返回的。 具体而言,SQL Server Native Client 9.0 返回 22007,用于字符串转换到日期时间的所有超出范围年份值,而从版本 10.0 开始的 SQL Server Native Client(SQL Server 2008 (10.0.x))返回 22008,当时日期在 datetime2 支持的范围内,但超出 datetime 或 smalldatetime 支持的范围。 |
如果舍入将更改日期,则 datetime 值将截断秒的小数部分,并且不舍入 。 | 在 SQL Server Native Client 10.0 之前,对于发送到服务器的 datetime 值的客户端行为是将它们舍入到最接近 1/300 秒的值 。 从 SQL Server Native Client 10.0 开始,如果舍入更改当天,此方案会导致小数秒截断。 |
datetime 值的可能截断秒。 | 使用连接到 SQL Server 2005 服务器的 SQL Server 2008 (10.0.x) Native Client (或更高版本)构建的应用程序,如果绑定到类型标识符为 DBTYPE_DBTIMESTAMP (OLE DB) 或 SQL_TIMESTAMP (ODBC) 且小数位数为 0 的数据,则会截断发送到服务器的秒数和秒数。 例如: 输入数据:1994-08-21 21:21:36.000 插入的数据:1994-08-21 21:21:00.000 |
从 DBTYPE_DBTIME 到 DBTYPE_DATE 的 OLE DB 数据转换不会再导致日期发生更改。 | 在 SQL Server Native Client 10.0 之前,如果 DBTYPE_DATE 的时间部分是在距离午夜的半秒内,则 OLE DB 转换代码将导致日期发生更改。 从 SQL Server Native Client 10.0 开始,当天不会更改(小数秒被截断且未舍入)。 |
IBCPSession::BCColFmt 转换更改。 | 从 SQL Server Native Client 10.0 开始,使用 IBCPSession::BCOColFmt 将 SQLDATETIME 或 SQLDATETIME 转换为字符串类型时,将导出小数部分值。 例如,将类型 SQLDATETIME 转换为 SQLNVARCHARMAX 类型时,返回了早期版本的 SQL Server Native Client 1989-02-01 00:00:00。 SQL Server Native Client 10.0 及更高版本返回 1989-02-01 00:00:00.0000000。 |
发送的数据的大小必须与 SQL_LEN_DATA_AT_EXEC 中指定的长度匹配。 | 使用 SQL_LEN_DATA_AT_EXEC 时,数据的大小必须与用 SQL_LEN_DATA_AT_EXEC 指定的长度匹配。 可以使用 SQL_DATA_AT_EXEC,但使用 SQL_LEN_DATA_AT_EXEC 有潜在的性能好处。 |
使用 BCP API 的自定义应用程序现在可以看到警告。 | 对于所有类型,如果数据长度超过某字段的指定长度,则 BCP API 将生成警告消息。 以前,该警告仅针对字符类型,而不会针对所有类型发出。 |
将空字符串插入到绑定为日期/时间类型的 sql_variant 中会生成错误 。 | 在 SQL Server Native Client 9.0 中,将空字符串插入到绑定为日期/时间类型的 sql_variant 中不会生成错误 。 SQL Server Native Client 10.0(及更高版本)在这种情况下正确生成错误。 |
更严格的 SQL_C_TYPE _TIMESTAMP 和 DBTYPE_DBTIMESTAMP 参数验证。 | 在 SQL Server 2008 (10.0.x) Native Client 之前,日期/时间值被舍入以适应 SQL Server 的 datetime 和 smalldatetime 列的刻度。 SQL Server 2008 (10.0.x) Native Client (及更高版本)应用在 ODBC 核心规范中定义的更严格的验证规则(小数秒)。 如果无法通过使用由客户端绑定所指定或暗含的小数位数在不截断尾随数字的情况下将参数值转换到 SQL 类型,则返回错误。 |
当有触发器运行时,SQL Server 可能会返回不同的结果。 | SQL Server 2008 (10.0.x) 中引入的变化可能会导致应用程序得到从 NOCOUNT OFF 有效时导致触发器运行的语句返回的不同的结果。 在这种情况下,您的应用程序可能会生成错误。 若要解决此错误,请在触发器中设置 NOCOUNT ON ,或调用 SQLMoreResults 以前进到下一个结果。 |