I found a difference in behaviour of adding date and datetime types in SQL Server 2012 and SQL Server 2016.
For the query:
select convert(date,getdate())+getdate()
I get error in SQL2016:
The data types date and datetime are incompatible in the add operator.
In 2012 it returns no error, just corect sum of dates.
What is the reason of such behaviour?
In SQL Server 2012, the operators were (silently?) changed to disallow mismatched types being added or subtracted. It apparently relates to the SQL Server 2008 ability to store Date and Time separately. You will need to cast to a common type (e.g. cast to date then to datetime).
Seems like a pretty large breaking change to me, but apparently Microsoft felt is was needed.
Related
After so many years, I have become part of a project that use SQL server. This time it's 2017. I found a very weird behavior when I create a table.
create table test (sampledate date)
If I run above and check the data type of column sampledate, it shows nvarchar instead of date. This causes an error in my application.
Btw I'm using DBVisualizer to check the data type, I believe this is not because of this tool.
Have a look at this section of the Microsoft documentation. It explains that with down-level clients, the backward compatibility of the date data type is ensured by being converted to String/Varchar. So it may really comes from the DBVisualizer usage.
For your app, check the version of the client you use.
I recently migrated a database from SQL Server 2008 to 2016. One of the side effects is that a raw output of a datetime field now contains milliseconds whereas before it didn't. Is there a way I can globally change this behaviour so a simple select * would output it without milliseconds.
Yes. Create a view that casts the data to a datetime2 datatype without the milliseconds. Then use that view for your joins if you so desire.
Or you can change the datatype of that column to a datetime2 type that does not have the millisecond precision and rebuild the table.
I am trying to query SQL Server from Apache Drill but I get some issues when the SQL Server tables contain datetimeoffset (SQL Server type) columns.
Any SELECT query from Drill to SQL Server on this kind of table lead to the response:
Error:
VALIDATION ERROR: Unknown SQL type -155
I am certain it comes from the datetimeoffset column in the table, since I tested the same kind of queries on tables with no datetimeoffset columns and obtained satisfying results.
I went through the documentation of Drill (e.g. this page https://drill.apache.org/docs/supported-data-types/) and tried to cast the datetimeoffset column to SQL supported types but nothing worked and Apache Drill kept answering me the same error.
Do you have any idea how to get through this please?
I can confirming that it is in fact a problem with DATETIMEOFFSET https://msdn.microsoft.com/en-us/library/bb677267.aspx not being well handled by the JDBC library.
Only resolution that I currently know of is to convert the data on the way out like so:
,CAST(my_datetimeoffset_col AS DATETIME2) as datetime_local
,CAST(SWITCHOFFSET(my_datetimeoffset_col, 0) AS DATETIME2) as datetime_utc
,DATEPART(TZ, my_datetimeoffset_col) as datetime_tz
You could choose to only output UTC or local time but in my experience DATETIMEOFFSET was chosen because both were going to be needed.
I have the requirement for dates that predate 1753, the minimum for datetime on SQL Server. DB-side, the solution is clear: change to datetime2 format. But it seems Informatica still treats the column as datetime. I suppose datetime2 is not supported. Is there any workaround that could enable me to insert pr-1753 dates in a datetime2 column?
Informatica version is 9.1.0, SQL Server 2008
If upgrading to a newer version of Informatica won't help or isn't an option, then you've got limited options. One option is to CONVERT the datetime2 to a suitable VARCHAR representation from the SQL Server side and then feed that to Informatica and let the implict casting of the value back to a suitable DATETIME do the hard work for you.
You'll need to make sure you are very careful with this though - if you end up migrating text dates such as 02/03/2015 02:33 etc - then there's a chance that if regional settings differ between databases or servers, you could import that as either 2nd of March or 3rd of Feb. It's best to use culture-invariant date formats, such as yyyy-mm-dd - that way it's always unambiguous.
-Steve
Many have come across the fact that SQL Server 2005 doesn't support datetime2. I was wondering if I can add it as a custom datatype instead.
I created a custom type with the name datetime2 so that's done.
Now I need to set the min date value, but is that even possible, since the custom type is based on the datetime type?
Short answer: No you can't.
Furthermore, DATETIME2 has additional properties, regarding fractional precision. I'd highly recommend any SQL Server DBA to migrate their server to at least 2008, to open up the rich features that are not available in 2005. I don't see any advantage to using something that is largely deprecated and over 10 years old. Especially since you're resorting to creating UDTs that will potentially create all kinds of RDBMS havoc in the future.
To get over this I changed the datatypes in the database to varchar. next I modified the stored procedure to do the conversion between the date entered in the search form and the values in the database. It's an ugly solution and I have to 'manually' compare year, month and day values, but it works in the end with a minimal effort. Customer happy, developer... on the fence :-)