Dateformat in .net Framework - sql

In my application rarely I am getting an error
The conversion of a varchar data type to a datetime data type resulted in an out-of-range value
I am aware this error is from SQL Server, that query I have formed from C# code.
Convert.ToDateTime(userDate).AddMonths(1)
Here both application server and database server date formats involved, hence I had doubt with date format difference between two servers.
Basically I want to know which date format will be considered for .net and SQL.
I am using .net framework 3.5 and SQL Server 2012.
Thanks in Advance.
Hari

There are many formats supported by SQL Server - see the MSDN Books Online on CAST and CONVERT. Most of those formats are dependent on what settings you have - therefore, these settings might work some times - and sometimes not.
The way to solve this is to use the (slightly adapted) ISO-8601 date format that is supported by SQL Server - this format works always - regardless of your SQL Server language and dateformat settings.
The ISO-8601 format is supported by SQL Server comes in two flavors:
YYYYMMDD for just dates (no time portion); note here: no dashes!, that's very important! YYYY-MM-DD is NOT independent of the dateformat settings in your SQL Server and will NOT work in all situations!
or:
YYYY-MM-DDTHH:MM:SS for dates and times - note here: this format has dashes (but they can be omitted), and a fixed T as delimiter between the date and time portion of your DATETIME.
This is valid for SQL Server 2000 and newer.
If you're using SQL Server 2008 or newer and the DATE datatype (only DATE - not DATETIME!), then you can indeed also use the YYYY-MM-DD format and that will work, too, with any settings in your SQL Server.
Don't ask me why this whole topic is so tricky and somewhat confusing - that's just the way it is. But with the YYYYMMDD format, you should be fine for any version of SQL Server and for any language and dateformat setting in your SQL Server.
The recommendation for SQL Server 2008 and newer is to use DATE if you only need the date portion, and DATETIME2(n) when you need both date and time. You should try to start phasing out the DATETIME datatype if ever possible

Related

SQL Server datetime2 in OPENQUERY

We're migrating form SQL Server 2005 to 2014 for a pretty large environment. And we've noticed that OPENQUERY behaves differently when interacting with MySQL database when it comes to datetime. Previously, it would translate just fine to DATETIME column. With 2014 (I assume started in 2008 or so), it now converts to DATETIME2 (with maximum precision). This causes problems when comparing to or inserting into DATETIME columns.
Is there a way to specify on a server-level (or specify default) for which type those will translate to? Rewriting all of the queries will be quite an undertaking, and I'd like to avoid this now, if possible (rather rewrite as we edit or introduce new things).
Try to Use VARCHAR datatype while migration of date fields, and it is always easy to Convert/Cast in various types as per need.

Default format DateTime SQL in Oracle, SQL Server and Firebird

I'm doing a manual INSERT where I have to format a DateTime value in C#. The resulting string is put into a a SQL query. I need a cross-platform format that can be hendled by Oracle, SQL Server and Firebird.
Example:
With yyyy-mm-dd you save the date correctly without relying on the language of the database.
I need the format not to uncouple from language but from vendor quirks.

Can I apply timezone changes to my UTC date in SqlServer?

So in SQL server I have been storing my dates as UTC, I also have a localized timezone in the format of 'AUS Eastern Standard Time', for example.
Is it possible to calculate the correct datetime with just information in Sql Server?
You didn't provide you environment info so I am proposing this for sql server and windows server.
There is no simple method to do this. As far as I know SQL server does not have time zones it can access. However, Windows does have this information. You could access this in SQL with a SQL CLR user defined table valued function using the time zone info class from .net. Then you just have to add the time zone offset minutes from the CLR function to the UTC date.

SQL Server datetime field issue

My personal computer is running Windows 7 (language turkish) and I installed SQL Server 2008. When I create a new database, the database language is Turkish_CI_AS
And I have a server with Windows Server 2003 (language english) and installed SQL Server 2008 on that server. I set the Regional and Language Options as Turkish. I am creating a database and selecting collation Turkish_CI_AS
But when I insert a row into a table on the server, an error occurrs:
The date format is invalid
You should always use unambigious formats like YYYYMMDD or YYYYMMDD HH:MM:SS so that no matter what setting the server/database is it will be added correctly. Read this for a better understanding http://beyondrelational.com/modules/2/blogs/70/posts/10898/understanding-datetime-column-part-ii.aspx

Why doesn't SQL Server have a pure date and pure time data type?

I have a few SQL Server tables with a datetime field that really only has to contain dates... and the fact that it's a datetime object violates data integrity, because it's possible for data to be inserted with a time - which isn't really valid for this field. The result is that we have to convert it and strip off the time every single time we use it. We've considered adding triggers to make sure that no data can even get in with a time attached... but it seems to me that this should really be part of the database software, and shouldn't need to be specifically programmed each time.
Why doesn't SQL Server have separate date and time data types? Is this going to change in the near future? Do other database platforms have this functionality?
SQL Server 2008 has DATE and TIME data types.
What version are you using?
SQL Server has a pure date and time data type since version 2008, they also added a bunch of new datetime types, now it also goes all the way back to year 1 instead of 1753