Hi we run 2014 enterprise. Our packages still reside on and run from msdb mostly executed from one sql agent job.
SQL Configs are enabled on nearly all our packages. I've always suspected whether or not these configs are working but have no verbose logs currently to see whether they are being considered. But that might not even be relevant to this question. I'm not sure.
We use network aliases in our ssis connectors whenever possible. So xxxxxxxx might be the alias name for the server on which our warehouse staging and warehouse tables reside. As you can imagine an alias like that resolves to different servers depending on where (dev vs qa etc) the package is running. And depending on some of our domain sharing, may be resolved in the host file or dns. Suffice it to say our predecessors felt that between sql configs and aliases, we were covered in spite of the fact that they are totally redundant. Host files trump dns.
I have a pretty decent ssis xml shredding query that Kev Riley helped with in this forum. It runs against msdb and is telling me what i want to know about two flavors of package we have our eyes on, especially their connectors.
One of the flavors of package we are looking at runs fine with alias xxxxxxxx in the warehouse connectors. Sometimes we have 2 connectors, one for ado and the other native sql. The other flavor will only run if the connectors have hardcoded server names. For example yyyyyyyy might be the sever name for warehousing in one of our qa environments. The error the second flavor gets if cm doesn't hard code the server at deployment is shown at the bottom of this post.
Both flavors have sql config turned on via environment variable and so on. But i'm not sure that's relevant. There is actually a 3rd flavor of package that could help here. It has xxxxxxxx in the warehouse connectors , sql config is NOT enabled and that flavor runs.
I started comparing xml from the first 2 flavors of package (specifically one package from each group) and have come up with this list of differences so far. Of course the goal would be for our cm group not needing to override aliases in our connectors at deployment time...
there is a checkpoint file name in flavor 1 (runs with aliases)
there is a computer create name and create person in flavor 2 (wont run with aliases)
fail parent on failure is true in flavor 2
Provider=SQLNCLI11.1 in flavor 2 vs without .1 in flavor 1
there is one other thing going on. we generally use a connector called aaaaaaaa.SSISconfig whose sql config table is supposed to hydrate connectors in the package. this connector is "pinted at" by an environment variable. and while that variable references an actual server, the server name in the pkg connectors is an alias in both flavors. but flavor 1 has an alias that is typically used for oltp systems and wouldnt have configs in its config table that are relevant to warehouse packages. while flavor 2's server name in the connector is alias xxxxxxxx. i can explain that further if questions come up about this.
Started: 4:38:23 AM
Error: 2020-11-14 04:38:23.32
Code: 0xC001000E
Source: onetimeloadbridge
Description: The connection "aaaaaaaa.STAGING ADO.NET" is not found. This error is thrown by Connections collection when the specific connection element is not found.
End Error