I have an SSIS package which iterates over a table, and for each row in the table, passes the values from two different columns as parameters to a stored procedure. At least, that’s what it is supposed to do. What it actually does is give me this error:
[Execute SQL Task] Error: Executing the query "EXEC sproc_AccessImport @mAccessLocation (SELECT M..." failed with the following error: "Must declare the scalar variable "@mAccessLocation".". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
I followed this tutorial in order to make the part that grabs the info, and the code that is supposed to execute the stored procedure is:
EXEC sproc_AccessImport @mAccessLocation (SELECT MVID FROM tbl_AccessMailDataFiles WHERE FileLocation = @mAccessLocation)
I’ve been looking around online, but haven’t found anything useful. This is the first time I’ve used SSIS, so I suspect I’m simply doing something wrong. Does anyone know what exactly that is? Thanks.
Edit: I tried mapping the variable as a parameter, with the options:
Variable Name: User::mAccessLocation
Direction: Input
Data Type: VARCHAR
Parameter Name: Path
Parameter Size: 200
And changed the SQL query to:
EXEC sproc_AccessImport @Path (SELECT MVID FROM tbl_AccessMailDataFiles WHERE FileLocation = @Path)
It now gives me the error:
[Execute SQL Task] Error: Executing the query "EXEC sproc_AccessImport @Path (SELECT MVID FROM tb..." failed with the following error: "Must declare the scalar variable "@Path".". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
So, really, the same error.
Depending on how your package is set up you may need to map the SSIS variables to the parameters within the Execute SQL Task. the specific error you are seeing is most liklely because you are using an OLEDB connection and the statment should probably read
If you are following the example you linked to then you would map the User::mAccessLocation to the first and second parameter. I hope that makes sense, but I’m not 100% on how you have this set up.