SSIS 2012 date formats dmy vs mdy
There are three SQL Servers:
I am migrating a large number of SSIS packages from PROD to both NEW_TEST and NEW_PROD servers.
Source data comes from flat text files
Source DATE data is in the format of dd/mm/yyyy (ie 5th of November 2015 is stored as 05/11/2015).
In SSIS, the definition of the DATE source column (text file) is Unicode string (DT_WSTR) and the target column (in DB table) data type is DATETIME so a type conversion happens between reading the data from text file and writing it into the DB table.
When I run the package on the PROD (old) server, the data is loaded correctly.
When I run the same (but upgraded to 2012) package on the NEW_TEST server, the data loads OK, too.
However, when I run the package on the NEW_PROD server, the data loads incorrectly (ie 05/11/2015 is loaded as 11th of May 2015 instead of expected 5th of November 2015). So it seems that the NEW_PROD server somehow converts UK (DMY) source date string using US (MDY) settings.
After spending a significant amount of time trying to understand what is going on, this is what I discovered:
I am trying to figure out how to make the data load correctly on the NEW_PROD server, using scheduler, without:
rebuilding its master database with the correct collation (impractical - too many databases, too much data)
changing source data type from DT_WSTR to DATETIME on all date columns in all SSIS packages (too many of them plus they work fine on the other two servers)
changing target data type (in the DB table) from DATETIME to VARCHAR(...)
So, long story short, I am trying to understand which element of the process is responsible for interpreting the source string as date and how to make it use DMY instead of MDY regardless of the incorrect collation setting. I thought I got it but then item 7. on the above list got me puzzled again.
Any faintest hints?
There are 4 places to check when dealing with date interpretation issues in SQL Server 2012:
Collation of the db (initially inherited from server collation)
SSIS language setting (LocaleID property at the package level)
Regional settings of the user executing the package (at OS level on the server where the package is executed)
Language setting of the database login associated with the execution context (the "Default language" property of a login)
There are probably priorities between them but I just set them all to the same value and the issue is now gone.
链接地址: http://www.djcxy.com/p/89088.html