I'd like to change display format of all dates/datetimes among entire instance/database (whichever is possible).
I tried changing default language for the instance and for single users and it doesn't work. It always displays YYYY-MM-DD. Can this be changed without messing with the code to always include FORMAT function?
Use the following function and write the format you want
SELECT FORMAT(GetDate(), 'yyyy-MM-dd')
Related
My local SQL Server 2016 setup at work decided not to accept the YMD date format after going through a reinstall. For example, the following query, that was and still is accepted in my coworkers' setups:
SELECT "id"
FROM test.dbo.tabEmp
WHERE "DateAdmission" <= '2021-12-31' AND "DateAdmission">= '2021-12-30' `
When I try to run it I see this:
The conversion of a varchar data type to a datetime data type resulted in an out-of-range value
however, if i rewrite the dates as 2021-31-12 and 2021-12-30, in the YYYY-DD-MM format, they are accepted.
I can't really convert or format it since the sql queries in our system are numerous and done so in a way that it would be nearly impossible to. Is there something that can be done? I tried changing windows' Date format but to no avail.
For the datetime and smalldatetime data types the format yyyy-MM-dd is not unambiguous (note that it is for the newer date and time data types). If you are not American, the date will very likely be interpreted as yyyy-dd-MM, and as there are not 31 months in the year you get an error.
For SQL Server, the formats that are unambiguous regardless of data type and language setting are yyyyMMdd and yyyy-MM-ddThh:mm:ss.nnnnnnn; ideally if you are using string literals use one of those formats as you can never get an error (unless you legitimately have an invalid date).
Otherwise you can explicitly CONVERT your value with a style code:
SELECT CONVERT(datetime, '2021-12-31', 126);
It seems that your new DB instance picked up a new language after the reinstallation.
The current language setting determines the language used on all system messages, as well as the date/time formats to use.
The date format setting affects the interpretation of character strings as they are converted
to date values for storage in the database. It does not affect the display of date data type values
that are stored in the database or the storage format.
You can run the following statement to return the language currently being used:
SELECT ##LANGUAGE;
This will tell us what the current language is and the date format (as well as a few other things):
DBCC USEROPTIONS;
Date format is modifiable via the following statements:
SET LANGUAGE us_english;
SET DATEFORMAT YMD;
Here is a good article on the subject: How to Change the Current Date Format in SQL Server (T-SQL)
It is also possible to modify SQL Server instance default language globally, once and for all: How to change default language for SQL Server?
I need to set a format for a column when the column "KPI" has a value with '%' I need that the value has the format for a percentage otherwise the currency format, so I have something like this:
=IIF(InStr(Fields!KPI.Value,"%")>0,Format(Fields!DIA.Value, "P"),Format(Fields!DIA.Value, "C"))
That expression works properly, but when I try to export that report to excel, that column is not summarizing when I select several columns as you will see in this picture:
As you can see excel is recounting but not summarizing, I have tried formatting each field from SQL Server and with this formula:
=IIF(InStr(Fields!KPI.Value,"%")>0,Format(Fields!DIA.Value, "###.#%"),Format(Fields!DIA.Value, "###,###,###,###.##"))
But the same happend when I export that report to excel, is there another way to handle this?
In order to make sure that Excel interprets a value as numeric, you can use the RenderFormat global variable to detect when the report is being rendered for Excel and not include the problematic formatting characters:
=IIF(InStr(Fields!KPI.Value,"%")>0,Format(Fields!DIA.Value, "###.#%"),IIF(OR(Globals!RenderFormat.Name="EXCELOPENXML",Globals!RenderFormat.Name="EXCEL"),Fields!DIA.Value,Format(Fields!DIA.Value, "###,###,###,###.##")))
If its critical that you display a thousands separator in your generated output you can use the Language global variable to detect the user's region and use the appropriate character. That check would take the general form Globals.Lanuage="en-US", depending on what particular regions are involved.
Here's an example of using the RenderFormat.Name variable to check the renderer in VS2013:
When doing a preview of the report, the format will show that the render type is RPL:
We have recently moved some data from an SQL Database instance to another one in another location.
I seemed to have noticed that there are some facets of our old database instance where the date is passed as String to the SQL server and SQL server is able to parse it properly. For example, the application would simply pass a string value of "15/01/2010" and the database would immediately recognize it as 5th of January 2010. Is there a setting in SQL server which I need to turn on or modify cause right now, when I passed the same string value, what happens is that an error is being generated cause it cannot understand the string value passed as a date.
Thanks for your inputs.
try
SET DATEFORMAT dmy
but you should only use 'safe' formats when using strings
same formats are YYYYMMDD and yyyy-mm-ddThh:mi:ss.mmm (no spaces). It doesn't matter with these 2 formats what your language settings are
Take a look here: Setting a standard DateFormat for SQL Server
If you need to convert output use cast or convert
select convert(varchar(30),getdate(),101)
03/08/2010
select convert(varchar(30),getdate(),101) +' '
+ convert(varchar(30),getdate(),108)
03/08/2010 15:21:32
Specifically, I wish to get the date format in a pure (ISO) format:
YYYY-MM-DD HH:mm:ss
I'm looking for a SET command or something that I can use.
I do not wish to rely on the culture setting of the server.
Note: I'm interested in the string format in which dates are returned, not entered.
To change the default format you need to add a new language (sp_addlanguage), set it's date format, then set the default language to it. More details can be found on this old technet article.
If you don't want to do that, then you can change it "per connection" using SET DATEFORMAT.
And if you don't want to do that, then you can use CONVERT to convert it to the relevent format string in each query.
Here's a handy article I found:
http://www.sqljunkies.ddj.com/Article/6676BEAE-1967-402D-9578-9A1C7FD826E5.scuk
What you're looking for is:
CONVERT(datetime,'05/08/2004',120)
This will return a date in the format you're after yyyy-mm-dd hh:mi:ss(24h) format (ODBC canonical, not ISO).
the formatting of the datetime depends on the client. You can use the convert function to display it as a string in the format of your choice.
When supplying dates to a stored procedure via a parameter I'm a little confused over which format to use for the dates. My original VBA syntax used the ADO Connection object to execute the stored procedure:
Set SentDetailRS = Me.ADOConnectionToIntegrity.Execute("dbo.s_SelectAggregatedSentDetailList '" & fCSQLDate(EffectiveDate) & "'", , adCmdText)
This works fine for me using the date syntax yyyy-mm-dd but when another user executes the code they recieve the error: 13 'Type Mismatch'.
After some experimentation I found that supplying the date in the format dd/mm/yyyy fixes this error for the user but now gives me the error!
Executing the stored procedure using a command object with parameters works regardless of the format of the date (I assume ADO is taking care of the formatting behind the scenes). I thought that using the format yyyy-mm-dd would work universally with SQL Server?
I'm also perplexed as to why this problem appears to be user specific? I noticed that my default language on SQL Server is 'English' whereas the other user's default language is 'British English', could that cause the problem?
I'm using ADO 2.8 with Access 2003 and SQL Server 2000, SQL Server login is via Windows integrated security.
Be careful, and do not believe that ADO is taking care of the problem. Universal SQL date format is 'YYYYMMDD', while both SQL and ACCESS are influenced by the regional settings of the machine in the way they display dates and convert them in character strings.
Do not forget that Date separator is # in Access, while it is ' in SQL
My best advice will be to systematically convert your Access #MM-DD-YYYY# (or similar) into 'YYYYMMDD' before sending the instruction to your server. You could build a small function such as:
Public function SQLdateFormat(x_date) as string
SQLDateFormat = _
trim(str(datePart("yyyy",x_date))) & _
right(str(datePart("m",date)),2) & _
right(str(datePart("d",date)),2)
''be carefull, you might get something like '2008 9 3'
SQLDateFormat = replace(functionSQLDateFormat," ","0")
'' you will have the expected '20080903'
End function
If you do not programmatically build your INSERT/UPDATE string before sending it to the server, I will then advise you to turn the regional settings of all the machines to the regional settings of the machine hosting SQL. You might also have to check if there is a specific date format on your SQL server (I am not sure). Personnaly, I solved this kind of localisation problems (it also happens when coma is used as a decimal separator in French) or SQL specific characters problems (when quotes or double quotes are in a string) by retreating the SQL instructions before sending them to the server.
I would guess that fCSQLDate function is culture-specific - i.e. it will parse the date based on the user's locale settings. That's why you see the problem.
Anyway, using queries with concatenated strings is always a bad idea (injection attacks). You are better off if you use parameters.
Access uses # as date field delimiter. The format should be #mm/dd/yyyy# probably the #mm-dd-yyyy# will also work fine.
Sorry I don't know mysql, but with oracle I would always explicity state the format that I was expecting the format to be in, eg: 'DD-MM-YYYY', to avoid (regional) date format problems
Why not use the format
dd mmm yyyy
There is only one way it can be interpreted.
You can use the Date() function to return a universal date based on the machine date and time settings. The region settings on the machine will determine how it it formatted on the client end. If you leave the field as strictle a DateTime field then the cleint region settings can format the date.
Going into the server, using the Date() function should aslo work (returning a universal date value).
Also, use a command object and parameters in your query when you pass them to avoid SQL injection attacks on string fields.