I am trying to run a simple update (just to establish it works) passing in a variable in the execute SQL task. It is within a Foreach loop and the incoming data is from a RecordSet destination. One of the fields in the recordset is UniqueID. I have a variable called User::UniqueID which holds the uniqueID value. I then have a second variable which is the insert statement of
"INSERT rptlifespan_transactionimagecopy SELECT " + (DT_WSTR, 20)@.[User::UniqueID] + ", null, null,null,null,null,null,null"
with delayvalidation set to True.
when I run the package i get the following error:
Error: 0xC0014054 at Execute SQL Task: Failed to lock variable "INSERT rptlifespan_transactionimagecopy SELECT 543, null, null,null,null,null,null,null" for read access with error 0xC0010001 "The variable cannot be found. This occurs when an attempt is made to retrieve a variable from the Variables collection on a container during execution of the package, and the variable is not there. The variable name may have changed or the variable is not being created.".
543 is the value of my first UniqueID so that bit is working ok. What I do not know is why the insert statement is failing.
Please help i have very little hair left!!
Is the SQLSourceType=Variable and the SourceVariable set to the name of your variable in the task editor? It looks as if maybe SQLSourceType=Variable and then you're setting the SqlStatementSource property through an expression to the value of your variable.|||
Hi Jay
i have checked and the SqlSourceType is Variable and the SourceVariable is set to User:: SQLTest2 which is the name of the variable that contains the Value INSERT blah blah blah....
When I run it the package fails with the same error and when I go back into the Execute Sql Task editor the SourceVariable has changed to the actual INSERT statement.
Any help appreciated
|||Delete the Execute SQL Task and try recreating it. I think, too, there must be an expression set somewhere incorrectly.|||
Racsco wrote:
When I run it the package fails with the same error and when I go back into the Execute Sql Task editor the SourceVariable has changed to the actual INSERT statement.
That shouldn't be happening. Maybe you should delete the Execute SQL task and recreate it.
|||
Hi Guys
thanks for your continuing help.
I have deleted and recreated it and now i get the following error
Error: 0xC002F210 at Execute SQL Task 1, Execute SQL Task: Executing the query "INSERT rptlifespan_transactionimagecopy SELECT 543, null, null,null,null,null,null,null" failed with the following error: "An error occurred while extracting the result into a variable of type (DBTYPE_I4)". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
any ideas?
|||Right. You're selecting more than one column and perhaps row, so you need to set the Execute SQL task to return a Full Result Set, not Single Row, and assign it to an OBJECT variable, not an integer variable.Any reason you're selecting a bunch of NULL literals? Drop them and add them later using a derived column if you desire. It will make working with your result set easier.|||
Phil Brammer wrote:
Right. You're selecting more than one column and perhaps row, so you need to set the Execute SQL task to return a Full Result Set, not Single Row, and assign it to an OBJECT variable, not an integer variable. Any reason you're selecting a bunch of NULL literals? Drop them and add them later using a derived column if you desire. It will make working with your result set easier.
It's an INSERT statement. There will be no resultset.
|||
JayH wrote:
Phil Brammer wrote:
Right. You're selecting more than one column and perhaps row, so you need to set the Execute SQL task to return a Full Result Set, not Single Row, and assign it to an OBJECT variable, not an integer variable. Any reason you're selecting a bunch of NULL literals? Drop them and add them later using a derived column if you desire. It will make working with your result set easier.
It's an INSERT statement. There will be no resultset.
Oh, right. I saw the INSERT and the SELECT together and misread it as two distinct statements.
So unless you have another SQL statement after the result set, set the result set to "None."|||
OK I am nearing frustration point!!
I have ripped it back to the bare minimum just so I can get it to work. I have a data flow that does a select on 1 column - UniqueID from a table into a recordset destination as an object variable called LoadList. This then flows to a Foreach Container set as Foreach ADO Enumerator with 1 Variable mapped as User:: UniqueID and index 0. Within the Foreach Loop is the Execute SQL task with SQLSourceType of Variable and SourceVariable of User:: SQLTest3 and result set set to none. I have 2 package level variables which are User:: UniqueID which is INT32 and value is initially 0 and User:: SQLTest3 which is "INSERT rptlifespan_transactionimagecopy SELECT " + (DT_WSTR, 20)@.[User::UniqueID] . So all i am trying to do is place the unique ID from the initial select into a different table.
Thanks once again for any help
|||
Racsco wrote:
OK I am nearing frustration point!!
I have ripped it back to the bare minimum just so I can get it to work. I have a data flow that does a select on 1 column - UniqueID from a table into a recordset destination as an object variable called LoadList. This then flows to a Foreach Container set as Foreach ADO Enumerator with 1 Variable mapped as User:: UniqueID and index 0. Within the Foreach Loop is the Execute SQL task with SQLSourceType of Variable and SourceVariable of User:: SQLTest3 and result set set to none. I have 2 package level variables which are User:: UniqueID which is INT32 and value is initially 0 and User:: SQLTest3 which is "INSERT rptlifespan_transactionimagecopy SELECT " + (DT_WSTR, 20)@.[User::UniqueID] . So all i am trying to do is place the unique ID from the initial select into a different table.
Thanks once again for any help
Your description sounds good. I assume you have a reason for doing it this way instead of just bulk loading into rptlifespan_transactionimagecopy from the data flow. So from your "frustration" comment I assume you're still having a problem. Is it the "An error occurred while extracting the result into a variable..."? I don't see how you could be getting that if your ResultSet is None and there are no mappings on the Resultset page.
|||Forget the data flow.
Code block because of the $@.!* emoticon conversions...
1 - Execute SQL Task: select uniqueID from table. Put that into an object variable (User::ObjectVar, perhaps) and set the result set type to "Full Result Set"
2 - Foreach Loop - Set it to loop on the object variable created from step 1 (User::ObjectVar). Map the output accordingly to your "holding" variable (User::UniqueID)
3 - Execute SQL Task within the foreach loop: SQLSourceType: Variable SourceVariable: User::SQLTest3
That's it. One thing to note: On the variable, User::UniqueID, make sure you have EvaluateAsExpression set to TRUE and that you are using the expression property to build the insert string.|||
Hi Phil
I have followed the above the only bit I am not sure on is where you say "you are using the expression property to build the insert string" as my variable User:: SqlTest3 contains the insert statement?
Cheers again
scott
|||
Racsco wrote:
Hi Phil
I have followed the above the only bit I am not sure on is where you say "you are using the expression property to build the insert string" as my variable User:: SqlTest3 contains the insert statement?
Cheers again
scott
On the properties for SQLTest3, since you are concatenating another user variable in your SQL statement, you need to do that in the expression. Set the property, EvaluateAsExpression = TRUE for the variable, SQLTest3. Then use the expression:
"INSERT INTO ... SELECT " + [User::UniqueID]|||
Hi Phil
Went home and slept on it, came in deleted the lot and started fresh. What I did differently was to cast the UniqueID as a string from the initial select rather than casting it in User:: SQLtest3 variable and it works fine now.
Thanks for all your help and patience and also thanks to JayH
scott
No comments:
Post a Comment