I'm getting a cast failure and I can't fathom why.
Here's what is failing :
select cast('16/04/2012' as datetime)
The error is :
"The conversion of a char data type to a datetime data type resulted
in an out-of-range datetime value."
If I use CONVERT with a 103 for format it works without issue as you would expect.
The server is set to british date format, therefore the MSSQL account should also be defaulting to britsh format. It's been rebooted, so it shouldn't be that the service is using a different date format.
This is a SQL2005 instance.
What I really want to know is, what could be causing the CAST to fail?
Use this code:
SELECT convert(datetime, '16/04/2012',105)
Have you tried SET DATEFORMAT DMY?
Date format and datetime format are not necessarily the same. While it may implicitly add the 00:00:00 for hh:mm:ss, maybe try adding that. Type 103 only includes dd/mm/yyyy, so it of course works.
You have a data format as MM:dd:YY, and cast tries to convert you '16/04/2012' which is 'dd/MM/yy' and throws exception because 16 is less then 12 monthes.
You can either change your data format in server settings or use SET DATEFORMAT statement before your query
Are you sure the server is British language format? If I run:
set language british
select cast('16/04/2012' as datetime)
Then I get:
2012-04-16 00:00:00.000
You can check the current session language with
select ##language
The session language defaults from the login in use, assuming it's a SQL Server-provisioned login (i.e. not a Windows user). To check the language for a given user:
select loginproperty('myuser', 'DefaultLanguage')
To make a permanent server change for all newly created logins:
EXEC sp_configure 'default language', 23
reconfigure
...where 23 is the langid obtained via sp_helplanguage.
Always use a language neutral date format - it will always work regardless of any settings:
CAST('YYYYMMDD', AS DATE);
4 digit year, 2 digit month, 2 digit day and NO separators. You will never again have to worry about default language settings.
Related
I am currently debugging a scenario in which dates need to be read from a string in a stored procedure.
The code that we have used is a simple convert statement.
e.g.
SELECT CONVERT(DATETIME, #dateInput)
The problem comes when I need to test the dates coming from the Chinese date format (yyyy.mm.dd) which is ISO 102.
What settings in Windows 10 / SQL Server must be set so that running SELECT CONVERT(DATETIME, '2020.05.16') will not return
"The conversion of a varchar data type to a datetime data type resulted in an out-of-range value."
I understand that using SELECT CONVERT(DATETIME, '2020.05.16', 102) would work but that would make the universal stored procedure incorrect when running with different windows date formats
Along with changing my windows settings to reflect the same date format I also changed:
My default language of my SQLEXPRESS server in Properties > Advanced > Default Language
My default language of my SQL User Login Properties > General > Default Language
This meant that it could read the direct string value without needed the ISO 102 identifier.
If the input value is always in the format yyyy.MM.dd then use the appropriate style code (don't rely on the language setting of the LOGIN):
DECLARE #StringInput varchar(10) = '2020.05.16';
SELECT CONVERT(datetime,#StringInput,102);
Ideally, however, instead of defining your parameter as a varchar define it as a datetime in the first place and have the application pass the correct data type; not a string. But that is a different question for the language your application is written in.
I am newbie to SQL Server and facing an issue. I am trying to convert date time which is in yyyy-mm-dd format to dd/mm/yyyy.
Used below code to change the format, which works well if dd <=12 and throws error The conversion of a varchar data type to a datetime data type resulted in an out-of-range value if dd>12
Declare #LastTime datetime
set #LastTime = '2015-06-12 12:08:18.690'
select convert(varchar, #LastTime, 101)
Tried with other output formats (from here) as well but no luck. Is there a way to fix the issue. I am using SQL Server 2008 version. Referred to many posts here but none of them solved the issue.
Thanks in advance.
If you only want to change the Date format try using this:
SET DATE FORMAT DMY
just write it on the screen, select it and execute it,that will allow you to work with DATE types in the format that you want till you close the session. the DATE type will be a String
The error is from set #LastTime = ... not from your select convert(...)
The error is because your current dateformat is dmy (implicitly set by default language)
If you would rather just change your dateformat then set dateformat mdy; will allow you to set #LastTime with the string 2016-06-13 (June 13th 2016).
If you don't want to mess with changing your dateformat you can specify the style of the string you use with convert when you are setting #LastTime, in this case that would be 121 (120 works as well).
rextester: http://rextester.com/CWZP33091
try this:
declare #LastTime datetime;
set #LastTime = convert(datetime,'2015-06-12 12:08:18.690',121);
select convert(varchar, #LastTime, 101);
have a look at the MSDN documentation for cast and convert at https://msdn.microsoft.com/en-us/library/ms187928.aspx
I'd guess that style 103 is the right one for you.
Give it a try with
select convert(varchar, #LastTime, 103)
I don't have the opportunity to check it out right now, as I don't have a MS SQL Server at hand.
As style 101 converts 'mm/dd/yyyy' it's clear why dd>12 causes an error, as convert is trying to convert 'mm' as a month with valid values from 1 - 12 and you provide 'dd' from 1-31.
Hope that helps
Take care
Andreas
SQL Server 2005
SELECT TOP 10 * FROM abc WHERE aDate = '2014-01-20'
When querying the above in SSMS it would normally return results where aDate is 20 January 2014. However for another user on the same server, it returns a date conversion error and only works when running the following query:
SELECT TOP 10 * FROM abc WHERE aDate = '2014-20-01'
I've checked regional language settings on the local machine and it's exactly the same as mine. Any ideas welcomed.
It is not the regional language settings on the machine that count in this case but the one defined on the database's options.
Anyway, to avoid having to rely on the regional language settings when parsing datetime in queries I would encourage you to use an invariant ISO date format : {d 'yyyy-MM-dd'}. Note there is also one for specifying the hours (ts).
It was account specific, the setting was stored as 'British - English' as opposed to 'English'. Changing this to 'English' resolved the problem. Thank you for your responses.
This error occurred as the SQL server tries parse the date value 20 as month and it causes error as 20 is not a valid month .Always It is good practice to use the date format 'dd-MMM-yyyy' which will work with any type of SQL COLLATION and regional language settings.
why if I do this on my SQL-Server 2008:
EXEC sp_configure 'default language', 5
reconfigure
Where the date format is dd/mm/yyyy:
select * from sys.syslanguages where langid = 5
returns
dateformat
----------
dmy
So if I do
select GETDATE()
I'm waiting for something like:
(no column name)
----------------
31/08/2013 13:20:44.590
but I get:
(no column name)
----------------
2013-08-31 13:20:44.590
I'm using SQL-Server 2008 Express compatibility mode 100
ADDED:
My real problem is that I need to pass to Stored Procedures dates in dd/mm/yyyy hh:mm to DATETIME variables, but the parser is still waiting for yyyy-mm-dd although I change the default language.
Thank you
The following is going to be rendered by Management Studio, irrespective of server settings:
SELECT GETDATE();
This is returning a datetime value to the client application, NOT A STRING. If you want a string, you can explicitly convert to a specific style:
As for the input to your stored procedures, please, please, please pass proper datetime parameters and not strings. There is no reason to allow users to enter freetext like 6/9/2013 when you really don't know if they meant September 6th or June 9th. The safe formats to pass to SQL Server are:
YYYYMMDD HH:MM:SS.nnn
YYYY-MM-DDTHH:MM:SS.nnn
Anything else can be misinterpreted. Which is why you shouldn't handle these as strings anywhere except at the final step of presentation / display.
you can use like this
Select CONVERT(varchar(100), GETDATE(),103)+' '
+CONVERT(varchar(100), GETDATE(),108) as now
the result is
I'm having a lot of difficulty with locale's in a particular instance of SQL Server 2008 R2 Express.
I'm in the UK and the following fails:
SELECT CAST('2012-12-31' AS DATETIME)
Error message:
The conversion of a varchar data type to a datetime data type resulted in an out-of-range value.
The Windows server locale is British English. My login locale is British English. Collation 'if that matters' is Latin1_General_CI_AS.
The database 'language' is English (United States) but then this is the same as another instance on a different server and the above SQL doesnt fail.
Any thoughts?
For the user making the database connection -- the SQL user -- set the language to English.
This is a setting specific to the SQL user of the connection issuing the query
One way to check if this is a problem... Run this in Management Studio and login as the SQL user who issues the query
SET LANGUAGE English
SELECT CAST('2012-12-31' AS DATETIME)
If this works, set the default language of the SQL user appropriately
Don't use YYYY-MM-DD for date literals, always use YYYYMMDD. This will never fail, regardless of locale, dateformat settings, language settings, regional settings, etc:
SELECT CAST('20121231' AS DATETIME);
A worthwhile read perhaps:
Bad habits to kick : mis-handling date / range queries
You should explicitly define the date format on your convert, in this case is 120:
SELECT CONVERT(DATETIME,'2012-12-31',120)
You can take a look at this page to see more date formats:
http://msdn.microsoft.com/en-us/library/ms187928.aspx