Connection string in dev and production

Question

I have a several servers that i want to pull data from.
I put the connection string in a OBJECT variable that come from configuration table and use it in the for loop mapping the value to local variable called connectionstring, this variable is the expression for the connection string property.
So far everything is working as expected.
my problem is that on my development i put my local server in the connection string variable so i will be able to connect to the server so i will be able to map source to destination.
When i deploy the solution to production the data in the configuration table is different obviously but i get a connection error that saying that it try to connect to my dev server.
Any idea why?
Thanks.

Answer 1

Seems like you haven't configured your package properly 
Here are some important consideration for SQL Server Configuration 
Now, let’s go through some important considerations that will help you to understand this configuration type better, and to avoid common implementation issues:
SQL Server configurations are very flexible, as you can store multiple configuration properties/values in the same table.
Multiple packages can use the same configuration table and filter.
You can have a configuration filter for each entry in the configuration table, or you can use the same filter to group a set of entries. If you use the second approach, make sure that all properties under the selected filter exist in the package
being configured. Otherwise warning messages are generated for those properties in the configuration filter that do not exist in the target package.
You can use existing database security and backup policies to protect the configuration table contents.
A drawback of this configuration type is that it relies on an SSIS connection manager to get access to the configuration table, but does not have built-in support for updating its connection string. In other words, the connection string that points
to the configuration table is hard-coded inside of the package, and you have to take extra steps in order to update it (for example, through an extra package configuration placed at the top of the Package Configurations Organizer, or in SQL Server 2008, by
using the /CONN option of DTExec).
The /CONN option of DTExec utility can be used to override the connection string used by the configuration only in SSIS 2008. This is because SQL Server 2008 Integration Services reloads configurations after applying DTExec command line options.
The configuration wizard can create the table and insert the required rows when they do not exist, but only if the direct method is chosen. The wizard never includes any sensitive data in the ConfiguredValue column of the table, and you would need
to manually update the table to add the required sensitive data.
If you use the direct method, and provide an existing configuration filter, the wizard will prompt you to either reuse the configuration information in the table or to override it with the property values from the current package. Make sure that
you understand this behavior, since choosing the wrong option could change the contents of the configuration table and produce unexpected execution results.
When you use the indirect method, the environment variable must contain the name of the configuration connection manager, the name of the configuration table and the configuration filter. The syntax should be:
“ConfigurationManagerName”;”Schema.ConfigurationTableName”;’ConfigurationFilter”
As with the direct method, you have to account for extra logic if you need to modify the connection string inside of “ConfigurationManagerName”