Share via

datetime 資料類型從 C 轉換成 SQL

  • 發行項

適用於：SQL ServerAzure SQL DatabaseAzure SQL 受控執行個體Azure Synapse AnalyticsAnalytics Platform System (PDW)

本主題列出從 C 類型轉換成 SQL Server 日期/時間類型時應考慮的問題。

下表所述的轉換適用于用戶端上所做的轉換。 如果用戶端為與伺服器上定義的參數指定小數秒精確度，用戶端轉換可能會成功，但當呼叫 SQLExecute 或 SQLExecuteDirect 時 ，伺服器會傳回錯誤。 特別是，ODBC 會將小數秒的任何截斷視為錯誤，而 SQL Server 行為則是四捨五入;例如，當您從 datetime2（6） 到 datetime2（2） 時，就會發生四捨五入。 Datetime 資料行值會四捨五入為秒的 1/300，而 Smalldatetime 資料行的秒數則由伺服器設定為零。

SQL_TYPE_DATE SQL_TYPE_TIME SQL_SS_TIME2 SQL_TYPE_TIMESTAMP SQL_SS_TIMSTAMPOFFSET SQL_CHAR SQL_WCHAR
SQL_C_DATE 1 - - 1,6 1,5,6 1,13 1,13
SQL_C_TIME - 1 1 1,7 1,5,7 1,13 1,13
SQL_C_SS_TIME2 - 1,3 1,10 1,7 1,5,7 1,13 1,13
SQL_C_BINARY（SQL_SS_TIME2_STRUCT） N/A N/A 1,10,11 N/A N/A N/A N/A
SQL_C_TYPE_TIMESTAMP 1,2 1,3,4 1,4,10 1,10 1,5,10 1,13 1,13
SQL_C_SS_TIMESTAMPOFFSET 1,2,8 1,3,4,8 1,4,8,10 1,8,10 1,10 1,13 1,13
SQL_C_BINARY（SQL_SS_TIMESTAMPOFFSET_STRUCT） N/A N/A N/A N/A 1,10,11 N/A N/A
SQL_C_CHAR/SQL_WCHAR （日期） 9 9 9 9,6 9,5,6 N/A N/A
SQL_C_CHAR/SQL_WCHAR （time2） 9 9,3 9,10 9,7,10 9,5,7,10 N/A N/A
SQL_C_CHAR/SQL_WCHAR （日期時間） 9,2 9,3,4 9,4,10 9,10 9,5,10 N/A N/A
SQL_C_CHAR/SQL_WCHAR （datetimeoffset） 9,2,8 9,3,4,8 9,4,8,10 9,8,10 9,10 N/A N/A
SQL_C_BINARY（SQL_DATE_STRUCT） 1,11 N/A N/A N/A N/A N/A N/A
SQL_C_BINARY（SQL_TIME_STRUCT） N/A N/A N/A N/A N/A N/A N/A
SQL_C_BINARY（SQL_TIMESTAMP_STRUCT） N/A N/A N/A N/A N/A N/A N/A

符號的索引鍵

  • -：不支援轉換。 診斷記錄會產生 SQLSTATE 07006 和訊息「限制資料類型屬性違規」。

  • 1 ：如果提供的資料無效，就會使用 SQLSTATE 22007 和訊息「不正確日期時間格式」產生診斷記錄。

  • 2 ：時間欄位必須是零，或是 SQLSTATE 22008 和訊息「小數截斷」所產生的診斷記錄。

  • 3 ：小數秒必須是零，或是使用 SQLSTATE 22008 和「小數截斷」訊息產生診斷記錄。

  • 4 ：忽略日期元件。

  • 5 ：時區設定為用戶端的時區設定。

  • 6 ：時間設定為零。

  • 7 ：日期設定為目前的日期。

  • 8 ：時間會從用戶端的時區轉換成 UTC。 如果此轉換期間發生錯誤，就會產生 SQLSTATE 22008 和訊息「日期時間欄位溢位」的診斷記錄。

  • 9 ：字串會根據遇到的第一個標點符號字元以及剩餘元件的存在，剖析並轉換成 date、datetime、datetimeoffset 或時間值。 接著，字串會轉換成目標型別，並遵循上表中此程式所探索來源類型的規則。 如果在剖析資料時偵測到錯誤，則會使用 SQLSTATE 22018 和訊息「轉換規格的字元值無效」產生診斷記錄。 對於 datetime 和 Smalldatetime 參數，如果年份超出這些類型所支援的範圍，則會使用 SQLSTATE 22007 和訊息「不正確日期時間格式」產生診斷記錄。

    對於 datetimeoffset，即使沒有要求轉換為 UTC，此值在轉換到 UTC 之後仍然必須在範圍內。 這是因為 TDS 和伺服器永遠會以 UTC 的 datetimeoffset 值，將時間正規化，因此用戶端必須在轉換成 UTC 之後，確認時間元件位於支援的範圍內。 如果值不在支援的 UTC 範圍內，則會使用 SQLSTATE 22007 和訊息「不正確日期時間格式」產生診斷記錄。

  • 10 ：如果發生資料遺失的截斷，就會使用 SQLSTATE 22008 和訊息「不正確時間格式」產生診斷記錄。 如果此值落在伺服器使用之 UTC 範圍所代表的範圍外，也可能發生這個錯誤。

  • 11 ：如果資料的位元組長度不等於 SQL 類型所需的結構大小，就會產生具有 SQLSTATE 22003 的診斷記錄，以及「超出範圍的數值」訊息。

  • 12 ：如果資料的位元組長度是 4 或 8，資料會以原始 TDS Smalldatetime 或 datetime 格式傳送至伺服器。 如果資料的位元組長度完全符合SQL_TIMESTAMP_STRUCT的大小，則資料會轉換成 datetime2 的 TDS 格式。

  • 13 ：如果發生資料遺失的截斷，則會使用 SQLSTATE 22001 和訊息「字串資料，右截斷」產生診斷記錄。

    小數秒位數（小數位數）取決於目的地資料行的大小，如下表所示：

    隱含縮放比例 隱含縮放比例
    類型 0 1..9
    SQL_C_TYPE_TIMESTAMP 19 21..29

    不過，針對 SQL_C_TYPE_TIMESTAMP，如果小數秒可以以三位數表示，而不會遺失資料，且資料行大小為 23 或更大，則會產生確切的三個小數秒位數。 此行為可確保使用舊版 ODBC 驅動程式所開發之應用程式的回溯相容性。

    對於大於資料表中範圍的資料行大小，會隱含小數位數 9。 此轉換應該允許最多九個小數秒位數，這是 ODBC 所允許的最大值。

    零的資料行大小表示 ODBC 中可變長度字元類型的無限制大小（除非套用SQL_C_TYPE_TIMESTAMP的 3 位數規則）。 使用固定長度字元類型指定零的資料行大小是錯誤。

  • N/A ：維護現有的 SQL Server 2005 （9.x） 和更早的行為。

另請參閱

日期和時間改善 （ODBC）