Im developing an app thats hosted up in Azure. On my development machine when i edit and save dates (UK format - saving to local sql server 2012) theres no problem. When I deploy the same code base to Azure (same database structure & sql server version - db hosted in VM in Azure) Im getting an error
'the value 23/01/2014' is not valid for contract date
has anyone else experienced anything like this and could give me some pointers ?
Ive set the os on the VM machine to be uk region and the underlying dates in the tables both locally and remotely are exactly the same format. Is there anything obvious I could be missing ?
the value 23/01/2014' is not valid for contract date
Please run dbcc useroptions to check the language and dateformat. And by default, the date format for SQL server is in U.S. date format MM/DD/YY, unless a localized version of SQL Server has been installed.
You could try to use the international format YYYYMMDD for sending the datetime data to SQL Server or pass the date in date format being used on the SQL Server.
We get data delivered to us in a flat file. A date column we want to store in a destination column called DWValidFrom has the following format:
2017-02-06T22:07:09Z
In SSIS using a Flat File Connection Manager, I set the datatype of said column to DT_DBTIMESTAMPOFFSET. It correctly shows us when checking the data in the Columns and Preview pages of the Connection Manager.
In SQL Server, I created the destination table, and defined the DWValidFrom column as datetimeoffset(0):
[DWValidFrom] [datetimeoffset](0) NOT NULL,
When I attempt to set the mappings in the OLE DB Destination object, which has been set to the SQL Server table in question, SSIS won't have it, and throws the following error:
The OLE DB provider used by the OLE DB adapter cannot convert between types "DT_DBTIMESTAMPOFFSET" and "DT_WSTR" for "DWValidFrom".
Suspecting something off with my regional settings, I issued the following query in Management Studio to ensure the format of the date wouldn't change:
SELECT CAST('2017-02-06T22:07:09Z' AS datetimeoffset(0))
This yielded the following result:
2017-02-06 22:07:09 +00:00
Why is SSIS not recognizing the column's proper data type? I do not have any other conversions or expressions set, so I'm confused as to why SSIS won't allow me to push a valid datetimeoffset.
We're using SQL Server 2014, Visual Studio 2015.
Thanks.
This sounds like the OLEDB source metadata is out of sync with the changes you made on the flat file connection manager. The quickest fix it would be to recreate the OLEDB source, but don't do that quite yet.
SSIS is not going to like that standard ISO format for the date. If you remove the "T" in the middle and the "Z" at the end it be ok. i.e.
2017-02-06 22:07:09
Because of this conversion issue in SSIS, the connection manager will probably fail in converting the string to datetimeoffset. So you will need to configure it as a string and then fix it's value in a derived column:
(DT_DBTIMESTAMPOFFSET, 0) REPLACE(REPLACE( [DWValidFrom] , "T", " " ), "Z", "")
Hope that helps,
m
The issue seemed to be that the OLEDB destination does not recognize datetimeoffset as a valid column format. Despite everything working in SQL Server and SSIS pushing a datetime that would be perfectly valid, the OLEDB destination wouldn't have any of it.
I considered using a SQL Server destination, but because the target server is a different server than the one we develop on, that wasn't an option either.
The fix for us was to instead format the columns using datetime as a datatype, which causes us to loose the timezone info, but because all of the dates were UTC, we really don't miss any data.
Quick Answer: Set DataTypeCompatibility to 0
I noticed in Connection Manager for my SQL Server Native Client 11.0 (OLEDB) connection, clicking on "All", then under the SQLNCLI11.1 section there's a value DataTypeCompatibility which was set to "80". 80 is code for SQL Server 2000 compatibility, well before they introduced TimeStampOffset (or in my case DT_DBDATE and DT_DBTIME2 types). I tried setting compatibility to 130, then 100, but "Test Connection" failed.
At https://learn.microsoft.com/en-us/sql/relational-databases/native-client/applications/using-connection-string-keywords-with-sql-server-native-client?view=sql-server-2017 there's a table, specifying information about this value
DataTypeCompatibility SSPROP_INIT_DATATYPECOMPATIBILITY Specifies the mode of data type handling to use. Recognized values are "0" for provider data types and "80" for SQL Server 2000 data types.
Changing the value to 0, then refreshing all of my connections using the OLEDB connection manager seems to have done the trick - now all my database's types are recognized rather than forcing it to nvarchar/DT_WSTR
In my SSIS package I read column type datetimeoffset(7) and write to column datetime2(7) (data flow task). Select in Source returns value i.e. '2015-01-01 00:00:00.0000000 +00:00' but in destination I got '2014-12-31 19:00:00.0000000'. This 5 hours difference is related to timezone on server which hosts sql service (both database and ssis package).
Any idea what is cause of this datetime change?
The problem appears to pertain to setting a datetime in the destination that hasn't happened yet on the server in the later timezone.
The following article should address your issue with several options for resolving:
http://www.mssqltips.com/sqlservertip/3173/handle-conversion-between-time-zones-in-sql-server--part-1/
When I export my tables from MS Access 2007 to SQL Server 2014 via ODBC driver, all tables go normally, but for tables when include date/time field generate code follows:
... "tt" datetime2(⪎Ѱ�撵)
These characters don't copypast in the message (screenshot from profiler http://i.stack.imgur.com/XwxVH.png)
When I convert date/time to string on my Access, all export normally.
How to fix this?
If your fields in SQL Server are of data type DateTime2, change these to DateTime.
I have created my database in sqlserver2008 r2,I want to degrade it to sqlserver2005.
I set the "SCRIPT For Server Version" option to 2005 while generating script,but I'm getting error with a table which has column with date data type.
Just change the script manually from date to datetime or smalldatetime. SQL Server isn't going to do that automatically for data types, unfortunately.