I recently came across some slightly strange behaviour on one of my SSIS packages and I thought it was worth posting up here to make people aware of it.
I was using the "Execute SQL Task" to insert values into a SQL Server datetime field. The values were stored in a SSIS datetime variable and I was using a parameterised query to insert them. The problem was that the day and the month were getting reversed so for example 11th March was getting inserted as 3rd November...12th March as 3rd December etc...
It turned out that the problem was outside of SSIS. The datetime value in SSIS is effectively passed to SQL Server as (e.g.) "12/03/2005 12:34:56" and it is the default language setting of the user under which the connection is being made that determines whether that string is interpreted as 12th March (i.e. the correct date) or 3rd December (the incorrect date).
I tested under 2 conditions, once with a default language of 'british' and the other with a default language of 'us_english'. In the case of the former my date was inserted correctly, and vice versa in the case of the latter.
Allan Mitchell helped me to work out what was going on here and in his words, SQL Server is effectively saying to itself :
Jamie is american. He said "05/03/2005". I am English. I read his
date in my format like this "03/05/2005"
which is a simplified summing up of the problem here.
[Note that changing the regional date and time settings on the box had no influence on this behaviour.]
I'm hoping something can be done to make sure this isn't an issue however because the issue is outside of SSIS I doubt that anything CAN be done. Its just something we're going to have to live with I guess! As long as people are aware of it. That's the important thing.
If you want to see what the default langauge is for each user then from within SQL Server Management Studio execute:
select
* from sys.syslogins
And if you want to change a user's default language you will need something like the following:
EXEC
sp_defaultlanguage 'int\jamie.thomson', 'british'
or
EXEC
sp_defaultlanguage 'int\jamie.thomson', 'us_english'
-Jamie
============================================================================
UPDATE 13th March 2005: Mark Durley from the SSIS dev team is currently looking into this issue so watch this space for updates.
In the meantime, following Paul Shotts' comment to this post (see comments section below) I looked into alternative methods of using an SSIS datetime where the the user's default language wouldn't cause any ambiguity. The solution is to use the SSIS DATEPART function to build a string in the form YYYY-MM-DD HH:MI:SS which contains no ambiguity about which number represents the date and which number represents the Month. This is done using expressions. In my Execute SQL Task I have an expression on the SQLStatementSource property as follows:
"insert into DatesDemo values ( '" +
(DT_STR, 4, 1252) DATEPART("yyyy", @[System::StartTime]) + "-" +
(DT_STR, 4, 1252) DATEPART("mm", @[System::StartTime]) + "-" +
(DT_STR, 4, 1252) DATEPART("dd", @[System::StartTime]) + " " +
(DT_STR, 4, 1252) DATEPART("hh", @[System::StartTime]) + ":" +
(DT_STR, 4, 1252) DATEPART("mi", @[System::StartTime]) + ":" +
(DT_STR, 4, 1252) DATEPART("ss", @[System::StartTime]) +
"')"
This works fine and always inserts the correct date. Hopefully Mark will come up with a fix that means I don't have to do this because its an overhead that I don't want to and shouldn't need to put up with.