package variables passed to Execute SQL Task

Hi,

I am having trouble getting the Execute SQL Task to recognize the package-level variables in an SSIS package. The tasks fail execution. The package contains three Execute SQL tasks and none of them receive the variables. However, when I replace the '?' in the code with the variable values they execute fine. These are the steps I have taken thus far:

Made sure the three variables are package level.

Verified I'm using an OLE DB valid connection.

Verified the variables are properly mapped in the parameters mapping section of the task properties.

Tried all 4 types of variable to parameter mapping (even though '?' in the query and '0,1,2..' in the name should work).

Changed the Bypassprepare property to 'True'.

Breakpoints and watch windows to verify the variable values.

I actually tried the simple tutorials on a one-liner SQL statement that uses variables, but had the same problem. I know there must be something simple that I'm missing here, but any info would be greatly appreciated!

Thanks!

Also, the code for the first package that holds the parameter is:

DECLARE @.DatabaseName varchar(100)
SET @.DatabaseName = ?
DECLARE @.SPID smallint

And, of course, when I replace the ? with the DB name in the Value field of the variable it executes.

The Parameter Mapping has the following values:

User:atabasename Input Varchar 0

And the Variables set up has the following values:

databasename package string DB_NAME

Is there a way to see the query after it reads the variables to see if I have something syntactically incorrect in the values? Please let me know if any further info would help.. I'm really stumped on this since I get the same results with examples found everywhere else too.

Thanks!|||

You could use an alternative approach to built the SQL statement. Create a new variable, let's say SQLStatement; then use an expression (set EvaluateAsExpresion=True) in that variable to form the SQL statement. something like:

"Select * from " + @.[User::Variable1]

Then in the execute SQL task set SQLSourceType=Variable and select the variable name in SourceVariable drop-down list.

I like this approach because you an see easily how the sql statement is being built.

|||Thanks for the quick reply Rafael. I am unclear as to how this would resolve the issue. The package contains three lengthy Execute SQL tasks, and the package needs to be replicated for several different databases that are independently accessed in a development environment. My original idea was to use the package variable to simply change the DB name. Are you saying I should try changing each task to a SQLSourceType=Variable and use a SQLStatement-like variable that uses an expression for the code presently used in the Execute SQL task? If so, it's definitely worth a try, but I'm still unclear as to how I'm misusing the package variables and I'm sure I'll find future situations where they will be useful. Any ideas?

Thanks again!
|||

jheywood wrote:

Are you saying I should try changing each task to a SQLSourceType=Variable and use a SQLStatement-like variable that uses an expression for the code presently used in the Execute SQL task?
Thanks again!

Yes, that is my idea. That give you the benefit of testing the expression and check how exactly the sql statement is gong to be sent.

jheywood wrote:

but I'm still unclear as to how I'm misusing the package variables and I'm sure I'll find future situations where they will be useful. Any ideas?

Not sure..did you try changing the value of ByPassPrepare in the execute sql task?

|||Yes, I tried that too. I was hoping it was maybe just some stupid syntax problem that I might have overlooked with the parameter or the variable, but I guess not.

I'll try the other method since that definitely seems like a viable option. Thanks so much for the help!

Please let me know if you think of anything else about the var use, or need more information. I'm really stumped on it.
sql

Package changes made and saved revert to prior state when package closed and re-opened

I copied and added an existing package as a new package to a project and have been having trouble with settings reverting to those for the original package after I modify and save the changes for the new package. Sometimes happens with the save itself, other times it happens when I close and re-open the package. Most cases are with connections that revert back to the original file reference, but there are also control flow and data flow elements that keep reverting back to either settings from the original package or defaults that result in the re-opened package being in error. Not sure how to get around this issue short of developing the new package from scratch which I'd rather not do since it is fairly complex. Any help anyone can provide is appreciated. Thanks.If I were you I'll try saving a copy of that problematic package in another folder. Open the original problematic package, and then do a save.

Then using a file-comparison tool like Winmerge, text-compare the original and copy packages. If they remain the same, perhaps something is totally wrong with your BI Studio.

Another thing to check is if those "reverting" properties are saved in an external XML configuration file. It is possible that for some reason that dtsconfig file has been set to readonly, hence your package picking up the original values over and over again.

Goodluck.|||

Thank you. The external XML configuration file was not set as readonly. I had a dtsconfig file that was common to all packages which a co-worker suggested may be the cause of my problem, but I'm not so sure that is the case. He also suggested disabling the use of a configuration file for the package I was having a problem with which I did, but I still have the issue of connection strings for connection definitions reverting to their original setting for the path and file name. This isn't too big a problem because at execution time I pass the actual path and file name in a user variable, but at definition time I have to always reset the path/filename.

I haven't tried the comparison option yet, but if disabling the configuration file doesn't solve my run time issues, I'll try that next. Thanks again.

|||Jeff, when you copy a package, you need to generate a new GUID for it. On the background of the control-flow, select properties. Then underneath the Identification section, select the Generate New ID option in the ID field. This should solve your problem.|||

Phil, Thank you for your help. I reset the package id as you suggested and also re-enabled package configurations and created a package specific configuration file. That seems to have solved the problem of data flow component definitions reverting to default values. However, I am still seeing some of the issues I had before - the file specification for a connection definition keeps reverting to that for the package from which the new package was copied. Am I misinterpreting how the connection definitions from one copy of a package to another work? Are they global to the two packages or are they independent copies? I thought that by creating a configuration file specific to the new package that the connection definitions would be independent of the source package.

I also get a message each time I re-open the new package that the connection string for the database connection and database datasource are not identical and need to be synchronized. I select OK to do the synchronization, but it doesn't seem to take.

Thanks again for your help. Any further insight you can provide is appreciated.

|||

Jeff-B wrote:

Phil, Thank you for your help. I reset the package id as you suggested and also re-enabled package configurations and created a package specific configuration file. That seems to have solved the problem of data flow component definitions reverting to default values. However, I am still seeing some of the issues I had before - the file specification for a connection definition keeps reverting to that for the package from which the new package was copied. Am I misinterpreting how the connection definitions from one copy of a package to another work? Are they global to the two packages or are they independent copies? I thought that by creating a configuration file specific to the new package that the connection definitions would be independent of the source package.

I also get a message each time I re-open the new package that the connection string for the database connection and database datasource are not identical and need to be synchronized. I select OK to do the synchronization, but it doesn't seem to take.

Thanks again for your help. Any further insight you can provide is appreciated.

Between the two copied packages, are you using different package config files? If you are sharing the same config file, then you'll run into the scenario you are describing.|||I had been using the same config file, but I created a new, separate config file for the new package assuming that was what I needed to do to make package specific changes to the connection definitions. When I created the new config file, I selected all the elements shown to be available (variables, connection definitions, etc.) and then began to make changes to connection defintions, but the changes don't seem to take. As soon as I do a save, the file specifications for connections revert to the settings for the original source package.|||Resolved most of my remaining issues by not using a config file. I realize that is not a proper solution, but for now it works. I need some additional work with config files before using them in my project.