I'm trying to use an Execute SQL Task in SSIS 2008 to map a store procedure output parameter to a package variable.
The package variable is SSIS type DateTime and the store procedure parameter is SQL type DATETIME.
The SQL Statement is EXEC GetCurrentDate #CurrentDate=? and in the parameter mapping screen, the parameter is mapped to the package variable with direction Output and Data Type DBTIMESTAMP specified.
When I run the package I get the following error:
[Execute SQL Task] Error: Executing
the query "EXEC GetCurrentDate
#CurrentDate=? " failed with the
following error: "The type of the
value being assigned to variable
"User::CurrentDate" differs from the
current variable type. Variables may
not change type during execution.
Variable types are strict, except for
variables of type Object. ". Possible
failure reasons: Problems with the
query, "ResultSet" property not set
correctly, parameters not set
correctly, or connection not
established correctly.
If I run a trace on the query being run I see the type is being assumed as datetime2:
declare #p3 datetime2(7)
set #p3=NULL
exec sp_executesql N'EXEC GetCurrentDate #CurrentDate=#P1 ',N'#P1 datetime2(7) OUTPUT',#p3 output
select #p3
Does anyone know why it is assuming the type is datetime2?
Thanks
Found the answer on a Micorsoft Connect bug report:
We are closing this case as this is expected behaviour and is a result of the new sql datetime type change. You are using a native oledb connection manager for sql task, in the process of COM interop, we use VARIANT to hold the value and the only way to prevent data loss is to store the value as BSTR variant. If you change User::dateParam to String type it will work, or you can switch to use managed connection manager to bypass the COM interop.
http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=307835
Try specifying the inout/output parameters as DATE rather than DBTIMESTAMP in the SSIS task.
This certainly works in SSIS 2005 packages I've worked on.
It's also worth taking a look at this link, which covers this as well as a couple of other issues with SSIS and dates.
Related
Hi I am trying to return a ResultSet from an "Execute SQL Task" in SSIS.
I am then trying to save the result in a "ResultSet" variable.
My Query works in the console and my connection is ok to.
Here is my Query
SELECT Src FROM [myDB].[dbo].[myTable] group by Src
Src is nvarchar(255)
When I execute the task I am getting following error
[Execute SQL Task] Error: Executing the query "SELECT Src
FROM [myDB].[dbo].[myTable..." failed with the following error: "The type of the value (DBNull) being assigned to variable "User::ResultSet" differs from the current variable type (String). Variables may not change type during execution. Variable types are strict, except for variables of type Object.
". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
I am also attaching the screen shots for the Task setup.
Please help.
ExecuteSQL Screen1
ExecuteSQL Screen2 - ResultSet setup
In SSIS 2012 within a ForEach loop using an ADO enumerator, you are unable to assign a null value to a variable of type String when the source value came from a SQL query returning a null value.
I would suggest Derived Column Transform feature of SSIS
you'll use the SSIS ISNULL function to detect the NULL value - and then do something with it.
More info about Derived Column Transform
For example transforming String column:
ISNULL([String-Column]) ? "There Was No Value" : [String-Column]
Hi I've an SSIS Package which Does tasks like a)Truncate Last 7 days data from a table if any and then re-load it and all theses are placed in a sequence container and it run's fine.Now I'm planning to remove the hard coded value of 7 and introduce a variable NoOfDays which I can provide at run time.Can this be achieved?
I added a variable and tried to map it to the parameter of the ExecuteSQL Task...It gave the following error:
I even want the value to be available to the next step Data Flow Task
[Execute SQL Task] Error: Executing the query "delete from USER_CONTENT where CONVERT..." failed with the following error: "The variable name '#NoOfDays' has already been declared. Variable names must be unique within a query batch or stored procedure.
Statement(s) could not be prepared.". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
The query I'm using is
delete from USER_CONTENT
where CONVERT(date,ISSUE_DATE)>=CONVERT(DATE,GETDATE()-7)
and it is against an OLE-DB connection.
I do not have enough points to post a comment so I will have to ask you this way: are you using query parameters with a "?", if not, then in order to use a package variable with a stored procedure, you will need to write your statement to use them, also, don't name your parameters, use the default 0,1,2 etc.. that the package assigns.
I have declared a variable at the package level compdate and am testing data flow to the variable by droping an Execute SQL Task in the Control Flow of the package.
In the task,
SQL Statement:
select ? = (getdate() - 1)
Parameter Mappings:
Variable Name: User::compdate
Direction: Output
Data Type: DATE
Parameter Name: 0
Parameter Size: -1.
Why am i getting error:
[Execute SQL Task] Error: Executing the query "declare #compdate date
set #compdate = (getdate() ..." failed with the following error: "Syntax error or access violation". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
I do not see why you need to execute an SQL statement to get the previous day as this can be done in various other ways.
To answer your question though, since you are trying to store the result of the SQL query from your Execute SQL Task you have to change the SQL statement that you have provided.
Your new query:
SELECT (GETDATE() - 1) AS DateVar
Where DateVar will be the single parameter that is returned which you need to map to your variable.
You need to delete your Parameter Mappings as they are not needed. Open up the Result Set tab and Add a new result. Set the Result Name to be DateVar and set the Variable Name to be your variable User::compdate
You then need to set up your Execute SQL Task to return a Single Row result set in the General tab, mapped to your variable. Select Single row for the ResultSet option.
Working with result sets is explained in great details here. Scroll down to the 'Working with a Single-Row Result Set' section, it has a great example which you can follow.
If you want to use without using the result set. try with following steps.
Create the stored procedure in your respective database. Following
code is an example.
CREATE proc GetYesterDay(#yesterday datetime output)
as
Select #yesterday=getdate()-1
Create the ADO.NET connection to run the stored procedure. In which, you can mention the direction of the input and output of the parameters.
Create the execute task and configure it as following screenshot.
Click on Parameter Mapping and configure as following screenshot.
Now SSISCompletedDate variable will be filled with respective data.
Hope this helps!
The Error from the execute sql task is
The type of the value being assigned to variable "User::ReturnResult" differs from the current variable type. Variables may not change type during execution. Variable types are strict, except for variables of type Object.
The SSIS package was working fine till date but suddenly it showed an error today .
The script which i wrote in execute sql task is
Declare #ReturnValue int
EXEC #ReturnValue = DATABASE.dbo.StoredProcedure
Select #ReturnValue
The result set is configured to single row and in the resultset
ResultName= 0
VariableName=User::ReturnResult
The return value from the stored proc is either 0 or -1 ( Success or failure )
Since it is a production issue i dont have access to SP or the tables . So can this error occur due to connection issue with the Sybase server or its an issue with the Stored proc
Your error message is telling you that the stored proc is no longer returning just the 0 or -1 you are expecting (could it be returning null?)
Use a tool like sql server profiler to verify the parameters being passed into the stored proc and emulate the same steps to understand why the return type is different.
I have recently joined a team where they are using JSON serialization to pass parameter arrays to SQL Server stored procedures where they are then deserialized and the required values extracted i.e. Each stored procedure has a '#Parameters' parameter of type VARCHAR(MAX). The framework creating and executing the command is written in C# and uses standard .NET types (SqlCommand, SQlParameter) etc.
It appears that when the serialized content is greater in length than a threshold that the stored procedure is not being properly executed but no exceptions are raised. Nothing appears to happen. Running SQL Profiler I have observed that there is no attempt to execute the stored procedure in SQL Server.
For example:
In one case there are just 30 instances of a type with no more than eight properties being serialized. The serialization succeeds and the value is assigned to the sql parameter in the parameters collection of a SqlCommand (there is only one parameter). The command is executed but nothing happens. If there are fewer occurrences of a type then it succeeds. When it does not succeed an exception is not being raised.
Using:
SQL Server 2008
C# .NET 4.0
JSON Serialization provided by Newtonsoft.
The SqlParameter in code is created as a varchar max.
Client Server architecture - there are no intermediary services.
Does anyone know of a limit for JSON serialized values being passed as a sql parameter with a SqlCommand or have any ideas as to what might be causing this behaviour?
I've figured out what was happening in my case. It had nothing to do with the serialziation of the value in a sql parameter as I found that if I waited long enough (5 -7 minutes in my case) that the procedure eventually executed.
In the stored procedure there is a cursor being used to extract the records of interest (this is a batch update procedure). This cursor was calling the CLR function to deserialize the Json for each value it required. By inserting the desirialized data into a temp table for use in the cursor the 'issue' was resolved.