SSIS 2012日期格式dmy vs mdy

 

有三个SQL Server：

  • PROD（2008 R2）
  • NEW_TEST（2012）
  • NEW_PROD（2012）

    • 我正在将大量SSIS包从PROD迁移到NEW_TEST和NEW_PROD服务器。

    源数据来自平面文本文件

    源日期数据的格式为dd / mm / yyyy（即2015年11月5日存储为2015年11月5日）。

    在SSIS中，DATE源列（文本文件）的定义是Unicode字符串（DT_WSTR），而目标列（在DB表中）数据类型是DATETIME，因此在从文本文件读取数据并将其写入到数据库表。

    当我在PROD（旧）服务器上运行软件包时，数据加载正确。

    当我在NEW_TEST服务器上运行相同（但已升级到2012）的软件包时，数据也会正常加载。

    但是，当我在NEW_PROD服务器上运行程序包时，数据加载不正确（即2015年11月5日装载为2015年5月11日，而不是2015年11月5日）。 因此，似乎NEW_PROD服务器以某种方式使用US（MDY）设置转换UK（DMY）源日期字符串。

    花了大量的时间试图了解发生了什么之后，我发现了这一点：

  • NEW_PROD服务器将排序规则设置为“SQL_Latin1_General_CP1_CI_AS”
  • NEW_TEST服务器已整理“Latin1_General_CI_AS” - 这与当前的PROD服务器匹配，因此NEW_PROD上的排序规则似乎不正确。
  • 除了上面的服务器级别之外，服务器级别的服务器设置之间没有其他区别。
  • 目标数据库在NEW_ *服务器以及当前的PROD服务器上都将排序规则设置为Latin1_General_CI_AS
  • 当我在本地机器上手动运行软件包时，无论目标是什么目标，都会正确加载数据。
  • 当我从NEW_PROD服务器上的预定作业运行包时，数据加载不正确。
  • 现在，一个有趣的事情是：当我从NEW_TEST服务器上的预定作业运行包但目标连接指向NEW_PROD服务器时，数据正确加载
  • 在所有服务器上，运行SSIS服务的用户都将默认语言设置为英式（sys.syslanguages中的langid = 23）。 这同样适用于拥有计划作业的用户。
  • 当我将SSIS包中的源数据类型定义从DR_WSTR更改为DATETIME时，无论程序包执行的位置如何，都会正确加载数据。
  • 当我在源和目标之间添加数据转换时，将该列从DT_WSTR转换为DB DATETIME，数据在NEW_PROD上加载不正确，但仍在NEW_TEST上正常运行。

    • 我试图找出如何使用调度程序在NEW_PROD服务器上正确加载数据，而无需：

  • 用正确的归类重建主数据库（不切实际 - 数据库太多，数据太多）

  • 在所有SSIS包中的所有日期列上将源数据类型从DT_WSTR更改为DATETIME（太多了，而且在其他两个服务器上工作正常）

  • 将目标数据类型（在DB表中）从DATETIME更改为VARCHAR（...）

    • 所以，长话短说，我想了解哪个进程元素负责将源字符串解释为日期，以及如何使其使用DMY而不是MDY，而不管错误的排序规则设置如何。 我以为我知道了，但后来的项目7.在上面的列表让我感到困惑。

    任何最微弱的提示？

    在处理SQL Server 2012中的日期解释问题时，有4个地方需要检查：

  • 数据库整理（最初从服务器整理中继承）

  • SSIS语言设置（包级别的LocaleID属性）

  • 执行程序包的用户的区域设置（在执行程序包的服务器上的操作系统级别）

  • 与执行上下文相关联的数据库登录的语言设置（登录的“默认语言”属性）

    • 它们之间可能存在优先级，但我只是将它们全部设置为相同的值，现在问题已经消失。

    链接地址: http://www.djcxy.com/p/89087.html

    上一篇: SSIS 2012 date formats dmy vs mdy

    下一篇: Git difftool ridiculously slow in Cygwin/MinGW