Connection managers do store connection information.
You thought that's what they were for and that is exactly correct.
Now the confusing part is that the connection information is stored in "both" places.
However, once the connection manager is made, that information has been copied into the package itself, and that registry entry might as well have never existed and does not need to exist in the future.
Now, if you want to see the last point demonstrated rather than just asserted (that is, that a connection manager's connectivity information is persisted to the package), create a IS package in BIDS with an OLEDB connection manager used in an execute sql task and execute the package sucessfully from BIDS.
Then,export those those registry entries and delete them (you'll reimport them later), using a tool like regedit.exe.
If you don't want to to mess with the registry, the following will demonstrate the point as well; double-click on the connection manager and point it to a different database.
Now, run the package . What happens Runs as before. Which database is hit The one the connection manager was changed too. Is the registry updated to point to the connection manager's current database No, it is not.
The connection information is persisted to the package.
Now, if you deleted the registry entries, re-import them.
BIDS is an acryonym for Business Intelligence development studio, which is the design-time environment hosted by Visual Studio 2005 for building BI projects ( Integration Services, Analysis Services, Reporting Services).