Im trying to download some data from web services using Web Service Task component in SSIS. Everything works fine when I insert required Input value manually. The required input value have to be in dateTime type but it only works when I munually write datetime in YYYY-MM-DD or YYYY-MM-DD HH:MM format.
But that of course is not what I wanted to do.
So I created a variable with DateTime data type with simple expression:
(DT_DATE) GETDATE()
But that gives me format DD.MM.YYYY HH:MM instead of YYYY-MM-DD or YYYY-MM-DD HH:MM.
When I execute the package it goes into error message:
[Web Service Task] Error: An error occurred with the following error message: "Microsoft.SqlServer.Dts.Tasks.WebServiceTask.WebserviceTaskException: Could not execute the Web method. The error is: Method 'ProxyNamespace.Service.Method' not found..
at Microsoft.SqlServer.Dts.Tasks.WebServiceTask.WebMethodInvokerProxy.InvokeMethod(DTSWebMethodInfo methodInfo, String serviceName, Object connection)
at Microsoft.SqlServer.Dts.Tasks.WebServiceTask.WebServiceTaskUtil.Invoke(DTSWebMethodInfo methodInfo, String serviceName, Object connection, VariableDispenser taskVariableDispenser)
at Microsoft.SqlServer.Dts.Tasks.WebServiceTask.WebServiceTask.executeThread()".
I think its only because my variable is in incorrect format. Any suggestions how to change it to desired dateTime format while data type of variable remains with DateTime option ? Thanks !
EDIT :
So I managed to solve the problem with the DateTime format, I simply changed the date format on my server to YYYY-MM-DD in the Windows environment (Control Panel - Region - Formats) and it also changed in SSIS.
But the problem still persists, when I check the box in the input section that I use a Variable and select my variable in the correct format as a DateTime with the correct value YYYY-MM-DD, I still get an error message and nothing happens.
Do you have any other solutions to my problem?
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'm working on a project running on an existing database. The problem is that datetime columns are inserted using a wrong format in SQL Server. The server uses datetime as Y-m-d and data is being saved as Y-d-m.
I've made some tests, and when saving to MariaDB datetime is saved properly.
There are custom fields for updated_at and created_at, so they are declared on the model.
In the model
class NotaFaturamento extends Model
{
const CREATED_AT = 'DT_CADASTRO';
const UPDATED_AT = 'DT_ATUALIZACAO';
This is the QueryLog print after saving data. As you can see in the query log, datetime format is correctly parsed to SQL Server.
Querylog
On Config\app.php
'timezone' => 'America/Sao_Paulo',
'locale' => 'pt-BR',
Is this something that needs to be configured on SQLServer? I've searched a lot about this, but most of the responses are regarding SQL Server separators.
I also declared protected $dateFormat = 'Y-m-j h:i:s:000A'; on the model but the same problem happens. The issue is also present when storing Carbon objects.
Regards.
EDIT
As pointed out by Dan, the issue could be the DATEFORMAT on the SQL Server being used as DMY. Also, as pointed this issue and answered by #dns_nx, there is a workaround to manually change dateformat for saving on SQL Server.
I've added to my model
public function getDateFormat()
{
return 'Y-d-m H:i:s.v';
}
And any other date attributes on the model should be declared as being date:
protected $dates = ['DT_EMISSAO', 'DT_COMPETENCIA'];
I don't think this is the proper way to solve the issue, but it does work. And you could create another basemodel as mentioned by #dns_nx.
Regards
I can't speak to Laravel/Eloquent specifically but a parameterized query with a strongly-typed datetime parameter will save the value properly. Since the value is not being saved correctly, it is because:
1) The actual parameter value provided for a datetime parameter type is wrong
2) The parameter type is (n)varchar with the value passed as a string that doesn't conform to ISO 8601 format
3) The parameter is passed as a string literal that doesn't conform to ISO 8601 format
For troubleshooting, run a SQL Trace (Extended Events or Profiler) on your dev database instance including batch_completed and rpc_completed events to capture the actual SQL queries. This will identify which of the above causes is the culprit. The rpc_completed will include both the parameter type and value. Be aware that with a datetime parameter type, the trace will always display the datetime value in YYYY-MM-DD hh:mm:ss.fff format, which is just a rendering of the actual binary value passed.
If the parameter type is (n)varchar, the non-ISO 8601 datetime string '2018-10-06 09:07:07.222' will be parsed by SQL Server using the current session DATEFORMAT setting. The default DATEFORMAT for a Portuguese language login is DMY but can be overridden by an explict SET DATEFORMAT command previously executed on the same session. With DATEFORMAT DMY and the string value '2018-10-06 09:07:07.222', the month and day portion will be parsed as month 6 day 10. Datetime literals are similarly parsed.
A quick search turned up this issue. Consequently, if you can't coerce a strongly-typed datetime to be passed by the application, a workaround may be to use datetime2(3) instead of datetime. SQL Server will parse datetime2 string '2018-10-06 09:07:07.222' as YYYY-MM-DD hh:mm:ss.fff regardless of the session DATEFORMAT setting. I recommend datetime2 for new development since it won't round the fraction seconds to 1/300 units and store greater precision values in less space.
OK, am a bit confused, I have an expression that turns the date into a UK format and with 3 years taken away, the expression is:
=cdate(format(DateAdd(DateInterval.Year, -3, now),"dd/MM/yyyy"))
This works happily when previewing the SSRS report in VS2015, however when I run it on the deployment server I get this message:
The DefaultValue expression for the report parameter ‘StartDate’ contains an error: Conversion from string "20/10/2013" to type 'Date' is not valid. (rsRuntimeErrorInExpression)
What is wrong with the expression to bring this error? and surely the same error should appear in the preview to?
Thanks
This will be due to regionalisation differences between your dev environment and your server. One of them will be dd/MM/yyyy and the other MM/dd/yyyy. Where possible pass date types or unambiguous string formats such as yyyy/MM/dd.
I am trying to calculate age as of a given YYYYMMDD date (2013-12-13) using an unsigned integer YYYYMMDD date of birth variable (dob) from a Sybase IQ 15.4 database (setdata). It isn't my database and I have no control over how the data are stored.
I am using the following code:
select
convert(date,convert(varchar,dob)) as yearborn,
DATE("2013-12-31") as present,
datediff(month,yearborn,present)/12 as age_in_yrs
from setdata
This works fine in the Interactive SQL tool I have, but when I run it using SAS connect with the same code (so I can get a log) I get this message:
ERROR: CLI execute error: [Sybase][ODBC Driver][Sybase IQ]Data exception - data type conversion is not possible. -- (dfe_Cast.cxx 835)
Update: SAS converts the commands into ANSI SQL. So I think I am looking for an ANSI way to do this, and that my function is not supported.
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.