SqlDateTime 溢出錯誤：DateTime.MinValue 超出 SQL Server 范圍的解決方案

錯誤現象

SqlDateTime overflow. Must be between 1/1/1753 12:00:00 AM and 12/31/9999 11:59:59 PM.

典型場景：.NET 程式將 DateTime.MinValue (0001-01-01 00:00:00) 寫入 SQL Server datetime 欄位，導致溢出。

根因：.NET 與 SQL Server 日期範圍不對齊

datetime 起始於 1753 年 (英國採用格里曆)，早於此日期的值無法儲存。

解決方案

方案 1：使用 SqlDateTime.MinValue (需顯式轉型)

// 錯誤：無法隱式轉換
// DateTime dt = System.Data.SqlTypes.SqlDateTime.MinValue;

// 正確：強制轉換
DateTime dt = Convert.ToDateTime(System.Data.SqlTypes.SqlDateTime.MinValue); // 1753-01-01 00:00:00
// 或
DateTime dt = (DateTime)System.Data.SqlTypes.SqlDateTime.MinValue;

SqlDateTime.MinValue 對應 1753-01-01，符合 SQL datetime 範圍。

方案 2：資料庫層面改用 datetime2 (SQL 2008+)

ALTER TABLE MyTable ALTER COLUMN CreatedAt DATETIME2(3) NOT NULL DEFAULT SYSUTCDATETIME();

• 範圍與 .NET DateTime 完全一致，消除溢出風險。
• 精度可至 100 奈秒 (vs datetime 3.33 ms)，儲存體 6-8 位元組 (vs 8 位元組)。
• 新專案預設使用 datetime2，僅相容舊系統保留 datetime。

方案 3：業務邏輯層攔截

public static DateTime SafeSqlDateTime(DateTime? input) {
  if (!input.HasValue) return DateTime.UtcNow; // 或拋出業務異常
  var min = (DateTime)System.Data.SqlTypes.SqlDateTime.MinValue;
  return input.Value < min ? min : input.Value;
}

補充：SQL Server datetime 預設值

• INSERT NULL → 自動填入 1900-01-01 00:00:00 (非 MinValue)。
• DEFAULT CONSTRAINT 未指定時同此行為。

最佳實務建議

1. 新資料表一律採用 datetime2(n)，n 依業務精度決定 (通常 0~3)。
2. Entity Framework Core 等 ORM 預設對應 datetime2，確認模型映射無誤。
3. 舊系統無法變更欄位型別時，在資料存取層 (DAL) 統一攔截轉換，避免業務代碼散落判斷邏輯。
4. 測試資料建立腳本務必覆蓋邊界值 (1753-01-01, 9999-12-31)。