I am trying to run the below procedure from SSIS using SQL Task.
ALTER PROCEDURE [dbo].[sp_Previous_Load_Dt_Tm]
AS
BEGIN
SELECT Extract_Dt_Tm = ISNULL(CONVERT(VARCHAR(20), MAX([Previous_Load_Date_Time]),120),'')
FROM [Test_table] WITH (NOLOCK)
END
I am returning as below
When I use the variable type as String in SSIS :
If I update the variable type to date it gives me the value:
Question ) I am not sure why its returning a date when I am converting the date to varchar in the procedure.
Is this happening at run time?
If you change the variable type to datetime at design time, and the string returned from the stored procedure is written to it during execution, this would most likely be due to SSIS performing an implicit conversion, i.e. successfully parsing a datetime value from the string.
I imagine the images you posted are at design time, with the string not having been written yet, and the datetime having defaulted to the current date and time?
I just removed and re added the variable. And it worked!!!! Not sure what the issue was.
Related
I am new to M.
When trying to call a SQL Server Store Procedure in M, I want to pass parameters to the exec command where SQL is looking for smalldatetime types. I have defined my parameters in PowerQuery as Date/Time, however, when they are added to the exec command I get various errors depending on how I include them.
PowerQuery Parameters
PowerQuery Code
Error Returned
If I change my query to convert the parameters from datetime to text using DateTime.ToText(startDate) I then get the error noting that my stored procedure needs a smalldatetime parameter type as follows, which is of course obvious:
DataSource.Error: Microsoft SQL: Error converting data type varchar to smalldatetime.
I also want to be able to submit the parameter in 'yyyy/mm/dd hh:mm' format, although if SQL will understand the month and day properly as my users will be in different regions of the world, then I will be happy. If I need to modify my stored procedure to work better with this, I can do that also.
Any help appreciated with thanks.
I've encountered a quite strange behavior of a procedure called from various environments. The procedure is implemented in Oracle environment.
function licence_update(p_licence ax_import_licence_vw%rowtype) return number;
When I run the statement from Oracle everything is allright:
declare l_res number := null; begin l_res := licence_update(p_licence); end;
But when the same procedure is called from MS SQL using OPENROWSET I get an error
ORA-1861: literal does not match format string.
EXECUTE ('BEGIN licence_update(p_licence); END;') AT LinkedServer;
There is a date attribute in the view ax_import_licence_vw, that certainly cause the error. If I take out this attribute the procedure always finished successfully.
So, I guess it happens because of NLS_DATE_FORMAT that is set up differently when the procedure is called. I took a look at the log table and found out the following information about nls_date_formats:
from Oralce: DD.MM.RR
from MS SQL: YYYY-MM-DD HH24:MI:SS
What kind of converting operation should be done to that date attribute to get rid of this error?
I'm taking the last updated date from SQL table as below:
SELECT CONVERT(DATETIME, [Value]) AS LastModifiedDate
FROM [WarehouseDB].[dbo].[tblWarehouseSettings]
WHERE Name = 'LastModifiedDate'
[Value] is varchar.
A variable as below:
I'm using an Execute SQL Task to get the date value & assign it to the variable. My Execute SQL Task Editor values set as below:
The task executed successfully but it doesn't get the value from the DB. Assigned value to the variable after the task execution is {12/30/1899 12:00:00 AM}
Can anyone figure out what I'm doing wrong here?
There are 2 things that caused this issue :
There is no need to specify #[User::LastUpdateOn] as an Output parameter in Parameters mapping Tab
Your SQL Statement is showing that you are converting [Value] column to DATETIMEOFFSET instead of DateTime and DT_DBTIMESTAMP is related to DateTime SQL Data Type
References
https://learn.microsoft.com/en-us/sql/integration-services/data-flow/integration-services-data-types
http://bidn.com/blogs/DevinKnight/ssis/1387/ssis-to-sql-server-data-type-translations
In an execute sql task. I have a column called LastEditedBY which is varchar in Source System 1. In the Execute Sql Task, all I do is:
Select cast ( LastEditedBy as INT) from Table1
All the values that are null at the moment. I then store it in a variable of type INT called LastEditedBy.
I then run a stored procedure in a second Execute Sql Task to insert into Source System 2, which requires the input to be of a data type INT.
Watching in the SSIS via the Watch Window, It takes a null and sets the variable to 0 instead of '', empty string.
Is this a defect? How can I ensure that instead of getting a 0 for nulls, I get a ''?
INT variables in SSIS will convert NULLs to Zeros, what I can recommend in your case is to declare the variable as a string and do the conversion to INT in a later stage, probably in your SP.
I have a stored procedure that takes a datetime parameter which is passed in as a string. Such as this:
Procedure:
CREATE PROCEDURE [dbo].[MyFancySP]
#MyStartDate datetime = NULL,
#MyEndDate datetime = NULL
AS
....
Call:
EXEC [dbo].[MyFancySP]
#MyStartDate = N'01/01/2012',
#MyEndDate = N'03/01/2012'
The stored procedure has been working like this forever. Now, here's the interesting part. As soon as I change the date to 03/27/2012 or past it, I get the following error: The conversion of a varchar data type to a datetime data type resulted in an out-of-range value.
The only place in the stored procedure where the dates are used is in the where clause. In case it has to do with it, I'll copy it in here as well:
WHERE
((#MyStartDate IS NOT NULL AND #MyEndDate IS NOT NULL
AND d.SomeDate >= #MyStartDate AND d.SomeDate <= #MyEndDate)
OR #MyStartDate IS NULL AND #MyEndDate IS NULL)
Any ideas why I'm getting the out of range exception on March 27th or beyond? This is running on SQL Server 2008 R2 by the way.
Thanks!
Execute the following on each new database connection.
SET DATEFORMAT DMY
After you do this, your problem should disappear. I suspect that your issue is conditioned by a combination of server locale, and whether the day-of-month is 13th to 31st or not.
Not only that you see the error, you may also be fetching data for incorrect periods without noticing; other layers of your software may be correcting for that, but maybe only in some cases.
What type is d.SomeDate? Is it a NVARCHAR by any chance? That would explain it, as the WHERE clause would contain in such case an implicit conversion that the rules of Data Type Precedence state that should occur as a DATETIME. The apparent randomness of the error occurs due to the simple fact that the query scans rows that have invalid dates in the d.SomeDate field. In such a case you're dealing with data purity issues and you should fix your tables, preferably by making the column a DATETIME.
In addition:
always use the canonical date format YYYYMMMDD (no delimiters) in string representation: EXEC [dbo].[MyFancySP]
N'20120101', N'20120301';. This format is independent of the host locale, DATEFORMAT and LANGUAGE settings, .
Read Dynamic Search Conditions in T-SQL. WHERE column=#value or #value is null stops query performance optimizations dead on its track. Read the article.