從 SQL Server 2005 Native Client 更新應用程式
適用於:SQL Server Azure SQL 資料庫 Azure SQL 受控執行個體Azure Synapse AnalyticsAnalytics 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 Native Client 自 SQL Server 2005 中的 SQL Server Native Client (9.x) 之後的重大變更。
當您從 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 以來 SQL Server Native Client 中已變更的行為 (9.x) | 描述 |
---|---|
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 資料行傳回 "NO" ,而非 "NO " 。 | 從 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) 和更新版本中不需要此一致性檢查,此一致性檢查已不再執行。 |
當日期超出範圍時傳回不同錯誤。 |
對於 datetime 類型,SQL Server Native Client 會針對超出範圍的日期傳回不同的錯誤號碼(從 SQL Server 2008 (10.0.x)開始。 具體而言,SQL Server Native Client 9.0 會針對字串轉換成 datetime 的所有超出範圍年份值傳回 22007,而從 10.0 版開始的 SQL Server Native Client 會傳回 22008,當時日期在 datetime2 支援的範圍內,但超出 datetime 或 smalldatetime 所支援的範圍。 |
datetime 值會截斷小數秒且不會四捨五入 (如果四捨五入會改變日期的話)。 | 在 SQL Server Native Client 10.0 之前,傳送給伺服器之 datetime 值的用戶端行為是要四捨五入到最接近的 1/300 秒。 從 SQL Server Native Client 10.0 開始,如果四捨五入變更日期,此案例會造成小數秒的截斷。 |
datetime 值的可能截斷秒數。 | 使用 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 之前, datetime 值會四捨五入以符合 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 以前進到下一個結果。 |