In my application we have to call SET DATEFORMAT YMD before each and every operation. In the master.dbo.syslanguages in entry for my language (polish, lcid=1045) there is dmy format.
So is there any way I could change this entry or create a new language that will be like old one, but with changed DATEFORMAT?
SQL Server 2005 removed the option to update system tables that was present in SQL Server 2000 (using sp_configure 'allow updates', 1)
Can you not change your client date format so it's recognised correctly regardless of DATEFORMAT settings? eg 4 figure year, ISO formats etc such as (not exhaustive) "21 feb 2008 14:32", "2008-02-21 14:32", "20080221 14:32" etc.
Related
I am using this version of SQL Server
Microsoft SQL Server 2019 (RTM-GDR) (KB4517790) - 15.0.2070.41 (X64) Oct 28 2019 19:56:59 Copyright (C) 2019 Microsoft Corporation Developer Edition (64-bit) on Windows 10 Pro 10.0 <X64> (Build 19041: ) (Hypervisor)
information about locale setting
select ##LANGUAGE;
-- result: us_english
I read reference document
(source: https://learn.microsoft.com/en-us/sql/t-sql/data-types/date-transact-sql?view=sql-server-ver15)
I have
DECLARE #date DATE = '12/10/05';
DECLARE #datetime DATETIME = #date;
SELECT #date AS '#date', #datetime AS '#datetime';
As reference document point out, I think it is mm/[yy]yy/dd (12/10/05; December 5th, 1910), but it return December 10th, 2005.
Is reference document wrong? How to easy-to-understand these format? How to understand and remember?
First thing is first - None of the Date/Time data types is stored with the display format in SQL Server.
Second, you've executed select ##LANGUAGE; and got back us_english - go on and run
SELECT dateformat
FROM sys.syslanguages
WHERE [Name] = ##LANGUAGE;
And you'll see the result of mdy - which means that the formats for string representations of date values is one of the following:
[m]m/dd/[yy]yy
[m]m-dd-[yy]yy
[m]m.dd.[yy]yy
Third, you should be aware of the fact that when dealing with SQL Server, the language settings are related to the default language of the login, which means different logins might have different language seetings, and of course, it is possible to change the language and / or the date format settings - which leads to the conclusion -
You should never rely on language settings for date/time string representations. Instead, use one of formats specified in ISO 8601, since these are the only two formats guaranteed to be interpreted correctly to a valid date/time value, regardless of the language and dateformat settings, and regardless of the actual data type, Even DateTime And that's juse One reason why you should never use DateTime again).
Installed Sql Server 2017 Express on Azure VM and wanted to change datetime format from MM/dd/YYYY to dd/MM/YYYY so for that I changed default language from us_english to British.
Edit: I am passing some dates from my application to database in DD/MM/YYYY format and database is not accepting because database has set for MM/DD/YYYY format (US format)
I tried multiple ways but none is working.
EXEC sp_configure 'default language', 23 ;
GO
RECONFIGURE ;
GO
and tried this also How to change the language and date format in SQL Server? but result is same.
Advance tab is although shows British but Datetime format is still MM/DD/YYY
The problem isn't the language of the database, or the Server, it's of the login.
You either need to provide the dates in an unambiguous format (yyyyMMdd or yyyy-MM-ddThh:mm:ss.sssssss) or change the language of the login:
ALTER LOGIN YourLogin WITH DEFAULT_LANGUAGE = BRITISH;
This query will give your languages available in Your Database...For Eg. English,German...etc..
select * from sys.syslanguages
Set Your language as your preference
SET LANGUAGE English
I have got several tables in my database (with data) that is formatted in the American standard of mm/dd/yyyy. Is there a way to convert the date to a British format (i.e. dd/mm/yyyy) that doesn't involve dropping and recreating the tables?
Thanks!
I set my data type to >date when I was creating my table. I can store dates in the format mm/dd/yyyy, but not dd/mm/yyyy.
As I've mentioned in my comment, dates are not stored with their display format - in fact, you can say that dates have no display format - only string representation of dates have a display format.
Whenever dealing with string literals representing date and datetime values in SQL server, use ISO 8601 datetime format (yyyy-MM-ddTHH:mm:ss or yyyyMMddTHHmmss).
SQL Server guarantees to properly parse this string representation into date / datetime values, without ambiguity.
Please note the T seperator between the date and the time. There is a very similar standard format, where the T is replaced with a white-space, but the DateTime data type have a bug parsing this format - and it is culture-dependent (Note that DateTime2 does not have that bug) - and that's another reason why you should never use datetime again.
When you use a string literal like '25/03/2018' it's easy for a human to see that it stands for March 25th 2018, but SQL Server will raise an error trying to parse this string into a date if the current value of DATEFORMAT is not DMY.
However, SQL Server will always parse ISO 8601 string representation of dates correctly, regardless of any local settings or previous set dateformat or set language statements etc'. '2018-02-01T15:40:50' will always be parsed is February 1st 2018, 3:40:50 PM.
Unless specified, As Martin Smith wrote in his comment, the default dateformat depends on the defualt language settings of the current login - so a query that works for one login might raise an error for another login - and that's another good reason never to trust culture-specific string representation of datetime.
DECLARE #dt DATETIME = '01/20/2019';
SELECT FORMAT( #dt, 'd', 'en-gb' ) AS 'UK'
Are you referring to the date format displayed by SQL Server Management Studio or a similar application? The format is controlled by Windows Control Panel settings, not by SQL Server. There is no internal format for dates in SQL Server.
This is defined by default from the machine where is running MS SQL Server.
To see all available cultures please do:
select * from sys.syslanguages
Then, you can change SQL Server language using:
SET LANGUAGE BRITISH
... and the date format will always be like you want.
Note: this will change all the database (not just the date format), the other way is to change the date format using the FORMAT function in T-SQL.
Since yesterday I started encountering errors related to date formats in SQL Server 2008.
Up until yesterday the following used to work.
EXEC MyStoredProc '2010-03-15 00:00:00.000'
Since yesterday I started getting out of range errors. After investigating I discovered the date as above is now being interpreted as "the 3rd of the 15th month" which will cause a out of range error.
I have been able to fix this using the following format with the "T".
EXEC MyStoredProc '2010-03-15T00:00:00.000'
By using this format its working fine. Basically all I'm trying to find out is if there is some Hotfix or patch that could have caused this, as all my queries using the first mentioned formats have been working for months.
Also this is not a setting that was changed by someone in the company as this is occurring on all SQL 2005/2008 servers
The language setting of the session can change this.
--This works
set language english
select cast('2010-03-15 00:00:00.000' as datetime)
--This doesn't
set language french
select cast('2010-03-15 00:00:00.000' as datetime)
With the T in between, it always works. If you want a space, then leave out the hyphens.
--This works
set language english
select cast('2010-03-15T00:00:00.000' as datetime)
--This works
set language french
select cast('2010-03-15T00:00:00.000' as datetime)
--This works
set language english
select cast('20100315 00:00:00.000' as datetime)
--This works
set language french
select cast('20100315 00:00:00.000' as datetime)
So my guess is that your app has changed... or some setting on your client computer.
To avoid these kind of problems you should always specify your date format. For your purposes you should use:
SET DATEFORMAT ymd;
See this MSDN page - note the comment that
ydm is not supported for date, datetime2 and datetimeoffset data types
so you might have to use a different format if you're using one of those data types.
It sounds like you've got a mixture of date styles - yyyy/MM/dd vs yyyy/dd/MM - which seem to be reverse UK and US style dates.
If all servers are showing the same behaviour it could be that just the machine executing the code has changed rather than the other machines/SQL servers in the network.
Double check that the date format or indeed culture settings are what you expect them to be on that machine. Assuming they weren't you might be able to find out what changes to the machine were made over the weekend from the event logs or Windows Update history.
Collation can effect dates, as well as the language.
To check what default language a server has installed, use the following SQL command:
sp_configure 'default language'
If the resulting value is 0, the default language U.S. English. If the result is not 0, run the following SQL command to find the installed default language setting and date format used:
select name ,alias, dateformat
from syslanguages
where langid =
(select value from master..sysconfigures
where comment = 'default language')
NOW as to the system updates updates, those were in 2007 to adjust to the DST changes mandated back then.
Machine specific: you CAN set the clock on a specific machine to NOT adjust for DST - check that setting per machine (Windows it is on Control Panel/Date and Time under XP for instance).
IF you choose to use the dashes, you may have issues in dates. If you take out the dashes, SQL Server will never misinterpret the data:
EXEC MyStoredProc '2010-03-15 00:00:00.000'
this is likely getting a time with a negative hour offset, which is in this case invalid.(just a guess)
vs
EXEC MyStoredProc '20100315 00:00:00.000'
Note that the T in there is the ISO8601 format, and thus the dashes are allowed.
Ok I just read a post over at Simons SQL Blog (http://cli.gs/hqaR4) about this specific issue. So one solution to this problem is to Use the new DATETIME2 datatype as it understands languages that doesn't use MDY dates
Does anyone know how you can get SQL Server 2005 Express to NOT install as US English?
All my win2k8 Regional Settings are set to English(New Zealand) but it always installs as US English.
I can't find anywhere to change it in the installer.
Okay, so date formats are the problem. So you mean your application is trying to insert dates something like this:
insert into Table1 (DateField1) values ('31/3/2008')
which fails because it thinks "31" is the month? Yeah I get that problem too in Australia. Your choices are:
1) Change the default language of the database, and the language for existing users. The language is actually configured on a per-login basis, so for example is SQL Management Studio, Security --> Logins, right-click a login, go to Properties, and change the "Default language" from English to British English. To ensure this also occurs for all new users, you need to change the default language of the server, which is done with:
select * from sys.syslanguages
.... then find the language you're looking for, i.e. British English and note the langid. To set it, say if British English has langid = 23:
sp_configure 'default language', 23
go
reconfigure
go
2) Make your application do date selects/inserts using an appropriate convert i.e.
insert into Table1 (DateField) values (convert(datetime, '31/3/2008', 103))
select DateField1 from Table1 where DateField1 = convert(datetime, '31/3/2008, 103))
3) Make your application do date selects/inserts using an international format. From BOL:
We recommend that you use date-time
formats that are not DATEFORMAT
dependent and are multilanguage. The
ISO 8601 formats,
'1998-02-23T14:23:05' and
'1998-02-23T14:23:05-08:00' are the
only formats that are an international
standard. They are not DATEFORMAT or
default login language dependent and
are multilanguage.
I'm guessing that in this case you can more easily change the database than the application, but if that's not the case then you should really make the application do things in a more global way. App/database design should try to be format-independent where possible.