80条INSERT语句中6条遇varchar转datetime越界错误，求排查方案

这种datetime转换的坑我之前也踩过不少，别着急，咱们一步步拆解问题：

• 优先核对日期格式与数据库的区域设置
  数据库的日期解析规则依赖于会话的DATEFORMAT和LANGUAGE设置，这是最常见的诱因。比如你的数据库默认是mdy（月/日/年）格式，而失败语句里的日期是'13/09/2024'（日/月/年），就会因为13不是合法月份报错。
  你可以先执行这条命令查看当前设置：

  SELECT @@DATEFORMAT, @@LANGUAGE;
  

  再把失败语句里的日期值单独拿出来测试转换：

  SELECT CONVERT(datetime, '你的失败日期字符串');
  

  看是否能复现错误，再对应调整格式或设置。

• 检查日期值的合法性
  有些日期字符串看起来和正常语句一样，但实际是无效值：比如'2024-02-30'（二月没有30号）、'0001-01-01'（超出SQL Server datetime的最小范围1753-01-01），或者带有全角空格、不可见控制字符。建议把失败的日期值复制到文本编辑器里，开启显示隐藏字符功能排查，或者直接用ISDATE('你的日期字符串')函数判断是否为合法日期。

• 排查会话级别的格式变更
  会不会在执行这6条语句之前，有其他操作修改了会话的日期格式？比如执行过SET DATEFORMAT dmy;但没恢复，导致后续日期解析规则变化。可以在INSERT语句前显式指定日期格式，比如：

  SET DATEFORMAT ymd;
  INSERT INTO 你的表 (...) VALUES (...);
  

  强制统一解析规则。

• 用显式转换替代隐式转换
  别依赖数据库的自动隐式转换，在INSERT语句里直接指定转换格式，彻底避免格式歧义。比如针对日/月/年格式的日期，用：

  INSERT INTO 你的表 (日期字段) VALUES (CONVERT(datetime, '15/09/2024', 103));
  

  这里的103是预定义的格式码，对应dd/mm/yyyy；如果是年-月-日格式，用20或120格式码都可以。

• 核对字段类型与日期范围
  确认你的表字段是datetime还是datetime2：datetime的范围是1753-01-01到9999-12-31，而datetime2支持到0001-01-01。如果失败语句的日期在datetime的范围外，就会报错，这时候要么调整日期值，要么把字段类型改成datetime2。

内容的提问来源于stack exchange，提问作者Simon SCHÖNEGGER