I have a simple query:
select df_id
from diasferiados
where df_dia = '17/9/2017 5:20:03 PM'
I run it on PC #1 and works fine.
But when I try to run it on PC #2, I get this message:
ERROR [22007] [Microsoft][SQL Server Native Client 11.0][SQL Server]Conversion failed when converting date and/or time from character string.
If I modify the date as follows (swap day and month):
'9/17/2017 5:20:03 PM'
It works fine on PC #2.
I can't modify my application so it must remain as the first case.
I'm guessing it's something about SQL Server Configuration but just can't find it.
If you need to provide date&time as string literals, you learned yourself that most formats are dependent on regional and language settings.
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.
So in your concrete case, I'm pretty sure this query would work just fine on both your PC's:
select df_id
from diasferiados
where df_dia = '2017-09-17T17:20:03'
If you use 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
Is there any way to change SQL server datetime? GETDATE() and CURRENT_TIMESTAMP show the wrong dates.
I read that SQL reads the date from the server settings where the SQL instance is installed. But on this server(Windows SERVER 2019) time, date and timezone are correct.
Only in SQL Server are those settings wrong. I've tried to find a solution for this issue over internet but I couldn't find any.
Only SYSUTCDATETIME() shows correct information.
GETDATE() and CURRENT_TIMESTAMP will be working correctly. They return the server's local time. If the time is "wrong" then it's because the time on the server is "wrong"; most likely because it thinks it's in a different timezone to where it physically is or has the wrong DST setting.
Clearly, however, the time is correct on the server for its location (in the sense of that if it's observing CET it would display 11:38 around now) as you state that SYSUTCDATETIME() returns the correct UTC time.
if the server does have the wrong time setting, however, the fix is fix the time on the server. Speak to your server administrator about that. YOu change change the values GETDATE() and CURRENT_TIMESTAMP return as they are based on the host's time. This is why I am confident the time is correct, likely it is either set to the wrong timezone or DST setting as the UTC time is correct.
If, however, the time is correct for where the server is physically located, then the answer is don't use GETDATE() or CURRENT_TIMESTAMP to get the value for your local time, instead (like you have) use SYSUTCDATETIME() or SYSDATETIMEOFFSET() and then convert the time to your timezone in the application layer.
It seems the server timezone was changed since the SQL Server instance was started. Run the query below to verify the timezone SQL Server is currently using:
SELECT CURRENT_TIMEZONE();
If the result is different than the OS configuration, restart the SQL Server instance for the new timezone to become effective.
Earlier my client was using SSRS 2008R2 with Oracle as transaction database. Recently they have upgraded to SSRS 2017 and now many reports are throwing following error:
ERROR: Throwing
Microsoft.ReportingServices.ReportProcessing.ProcessingAbortedException:
[AbnormalTermination:ReportProcessing],
Microsoft.ReportingServices.ReportProcessing.ProcessingAbortedException:
An error has occurred during report processing. --->
Microsoft.ReportingServices.ReportProcessing.ReportProcessingException:
Query execution failed for dataset 'Ds_Main'. --->
Oracle.ManagedDataAccess.Client.OracleException: ORA-01830: date
format picture ends before converting entire input string
After closely looking into report query, I have noticed that this error is for all those reports where oracle function TO_DATE(<Date Value>) has been used without date format. For example:
To_date(:Date_Parameter) -> this syntax throws above mentioned error
To_Date(:Date_Parameter,’MM/DD/YYYY’) -> this syntax works perfectly
I am willing to know:
what has changed in SSRS 2017 vs SSRS 2008 R2 that is causing this issue because same reports are working as expected in SSRS 2008 R2 and it is throwing above error in SSRS 2017.
Is there is any suggestions to fix this issue without updating bunch of reports?
what has changed in SSRS2017 vs SSRS2008R2
SSRS 2008 used the old System.Data.OracleClient. In SSRS 2016 and later you have to install the Oracle ODP.NET provider, built and supported by Oracle. So probably just a difference in how the NLS_DATE_FORMAT session parameter is set by the two drivers.
You can see your setting if you add a dataset to your report with this query:
select parameter, value
from nls_session_parameters
where parameter like 'NLS%'
order by parameter
Unfortunately there doesn't appear to be a way to globally change the client date format in Oracle.ManagedDataAccess, so you'll have to make all the changes in the report dataset queries.
Alternatively you can try to ensure that you are passing Date parameters and not string parameters. If you pass a date to Oracle's to_date() function, you don't need to specify a format.
The docs for SSRS 2014
"This built-in data source type is based on the .NET Framework Managed Provider for Oracle and requires an Oracle client software component."
And for SSRS 2016 "This built-in data source type uses the Oracle Data Provider directly and requires an Oracle client software component."
Trying to figure out the issue
I don't think the issue is related to the Visual Studio upgrade. It is related to the date format passed as a parameter to TO_DATE() function.
Based on the official documentation of the Oracle / PLSQL: ORA-01830 Error Message:
Cause: You tried to enter a date value, but the date entered did not match the date format.
In Oracle, the default date format is generally DD-MON-YYYY. If you try to enter a date value that does not comply with this format.
You seem to have passed the date parameters in the dd-MMM-yyyy format and now they are passed as MM/dd/yyyy.
First of all, check that the regional setting or the applications Culture information didn't change.
Possible workarounds
You can fix the issue using several approaches:
(1) Handling the parameters date format
If you do not want to edit all code, then it is easier to force the parameter data string format, make sure that all parameters passed to TO_DATE() function are in following format (or try to change the default date format from the OS regional settings):
dd-MMM-yyyy example: 01-AUG-2019
(2) Adding the date format to TO_DATE function
If you are sure that the date parameters format is fixed and will not change then you can edit your code as you mentioned in the question:
To_Date(:Date_Parameter,’MM/DD/YYYY’)
(3) Pass the date and format as parameters
This also requires changing the code, but you will pass the date and format as parameters.
To_Date(:Date_Parameter,:DateFormat_Parameter)
SQLFiddle demo for parsing dates
You may find other methods at the following link:
ORA-01830: date format picture ends before converting entire input string / Select sum where date query
Update 1 - Making common change in multiple reports
While searching I found the following link providing a method to loop over reports and make changes. You have to only replace To_Date(:Date_Parameter) with To_Date(:Date_Parameter,’MM/DD/YYYY’):
SSRS - Make common change in multiple reports in one click
Update 2 - Other possible workarounds
Forcing Culture info by editing ReportViewer.aspx
You can edit the ReportViewer.aspx file is located in the SQL Server reporting services directory, and force the culture info used within reports. Check out the following question it will give you more details:
I want Datetime Parameter in DDMMYYYY Format in ssrs report
Changing the browser language settings
Check the following link (read Mike Honey and Nick St Mags answers):
SSRS Datetime Parameter value should display in DD/MM/YYYY format
Update 3 - Issue cause
In addition of what #DavidBrownie posted i found the SQL Server 2008 R2 documentation:
Oracle Connection Type (SSRS 2008 R2)
Where they mentioned:
This built-in data source type is based on the .NET Framework Managed Provider for Oracle and requires an Oracle client software component.
Also if you take a look at SQL Server 2017 documentation:
Oracle Connection Type (SSRS 2017)
This built-in data source type uses the Oracle Data Provider directly and requires an Oracle client software component.
In addition, referring to Microsoft OLE DB Provider for Oracle documentation (which is the old used provider). They mentioned that:
This feature will be removed in a future version of Windows. Avoid using this feature in new development work, and plan to modify applications that currently use this feature. Instead, use Oracle's OLE DB provider.
Which is the reason for changing the provider used to connect to Oracle in Reporting Services.
Im developing an app thats hosted up in Azure. On my development machine when i edit and save dates (UK format - saving to local sql server 2012) theres no problem. When I deploy the same code base to Azure (same database structure & sql server version - db hosted in VM in Azure) Im getting an error
'the value 23/01/2014' is not valid for contract date
has anyone else experienced anything like this and could give me some pointers ?
Ive set the os on the VM machine to be uk region and the underlying dates in the tables both locally and remotely are exactly the same format. Is there anything obvious I could be missing ?
the value 23/01/2014' is not valid for contract date
Please run dbcc useroptions to check the language and dateformat. And by default, the date format for SQL server is in U.S. date format MM/DD/YY, unless a localized version of SQL Server has been installed.
You could try to use the international format YYYYMMDD for sending the datetime data to SQL Server or pass the date in date format being used on the SQL Server.
We are using Microsoft SQL Server Reporting Services, whether is it SQL Server 2005, 2008, 2012 or 2014, even on Microsoft Dynamics CRM Online SSRS we have same problem.
We are using English display language, however we use our local region format (Croatian) which has date format dd.mm.yyyy. And SSRS rdl file is configured in this way.
Problem is that report (.rdl) parametar for date is by default in incorrect format. Original date picker writes date in format: dd.mm.yyyy which is correct, however then we have error - rsReportParameterTypeMismatch
The temporary solution is to manually override text box by user for date parameter and remove latest character (period) so date than looks like dd.mm.yyyy, and then report works.
Is there any solution how to fix this from report.rdl side, so that users can use default date picker (with or without last character - period after year) without rsReportParameterTypeMismatch error ?
Since the problem persists on CRM Online SSRS (cloud) also, I am not able to modify any server settings there.
Have you tried changing the Report language property on the Report Element? This will change the formats of dates and integers but will not translate strings.
I installed SQL server and reporting services with him, when my regional settings is set to US, date format is been mm/dd/yyyy. Now, I changed region settings to German in tab Formats, Location and also System locale for non unicode programs.
My problem is that when I try to enter parameter for report, datetime format in report manager has same format like before mm/dd/yyyy. I try to re-create database for reporting services but with no luck.
I can not change application to send this us format to reporting services.
Windows server 2012 is OS.
Tnx...
There are a few things you can do:
You can try changing the Language on your report files (Properties - Location - Language) to match the same language on the database.
When you pass a parameter to a query, instead of using the parameter value, pass it as an expression like this: =Format(Parameters!Date.Value,"yyyyMMdd") which will convert it to a date format which will be accepted by any language setting on the database.
This got me for a while - finally found that you have to make sure the data type for the parameter (in the parameter properties) is set to datetime not text.