首先咱们直接戳破核心问题：datetime类型的上限就是9999-12-31，当你对值为'9999-12-31'的TERM_DT执行DATEADD(d, 1, T1.TERM_DT)时，结果必然超出datetime的范围，直接触发溢出错误——这是数据类型的硬限制，没商量。

接下来聊为什么过滤条件T1.TERM_DT < convert(datetime,'12/31/9999')没生效，还出现Master库正常、其他库失败的差异：这大概率是数据库日期解析的设置差异搞的鬼。

Master库的默认语言/日期格式（比如DATEFORMAT设为mdy）能正确把'12/31/9999'解析成12月31日，但其他数据库的设置可能不一样（比如是dmy），这时候'12/31/9999'会被当成“31月12日”，显然是无效日期，SQL Server会自动把它转成一个默认有效日期（比如1900-01-01），导致你的过滤条件完全失效，那些TERM_DT='9999-12-31'的记录依然会进入后续的DATEADD操作，最终触发溢出。

具体解决步骤： #

• 第一步：消灭日期解析的歧义
  永远用SQL Server无歧义的日期格式来规避区域设置影响，比如ISO 8601标准的'9999-12-31'，配合格式代码确保解析准确：

  T1.TERM_DT < CONVERT(datetime, '9999-12-31', 23)
  

  这里的23对应yyyy-MM-dd格式，不管数据库怎么设置都不会解析错。

• 第二步：从源头或执行时规避溢出
  要么在子查询T1里就提前过滤掉TERM_DT等于最大值的记录，从根源避免溢出：

  SELECT 
      ROW_NUMBER() OVER (PARTITION BY PFX,ID ORDER BY EFF_DT)AS 'ROWNUM', 
      PFX, ID, EFF_DT, TERM_DT
  FROM [Database].dbo.Table1 
  WHERE DATEDIFF(dd, EFF_DT, TERM_DT) NOT IN (0,1)
    AND TERM_DT < CONVERT(datetime, '9999-12-31', 23)
  

  要么在DATEADD时加判断，不对最大值执行加法：

  CASE WHEN T1.TERM_DT < CONVERT(datetime, '9999-12-31', 23) THEN DATEADD(d, 1, T1.TERM_DT) ELSE NULL END
  

• 第三步：统一数据库设置（可选）
  如果需要让其他数据库和Master库行为一致，可以检查并调整数据库的语言与日期格式：

  -- 查看当前数据库的语言和日期格式设置
  SELECT @@LANGUAGE, DATEFORMAT;
  
  -- 修改数据库默认语言（需管理员权限）
  ALTER DATABASE [你的数据库名] SET DEFAULT_LANGUAGE = us_english;
  

  不过更推荐在查询里显式指定日期格式，这样不受数据库设置影响，通用性更强。

另外提个小细节：你原查询里的子语句有多余的逗号（比如TERM_DT, FROM [Database].dbo.Table1），还有FULL OUTER JOIN后的WHERE条件会把T1为NULL的记录过滤掉，相当于变成了INNER JOIN，如果确实需要全连接逻辑，得调整WHERE条件哦。

内容的提问来源于stack exchange，提问作者user966424