cjard: thank you for your reply. I should have posted this on Monday (11/19/07).
We were using My.Settings to store the connection string; but, the type was "User" instead of "Application" and we were not deploying the application correctly.
My.Settings is an odd beast
Settings of type (Connection String) are application scoped which simply means that they cannot be changed at runtime (ok, they are stored elsewhere but that's an aside). THe (Connection String) type is a custom type that is TOSTRING()ed by the runtime whenever it wants to use a connection string (every time you use a tableadapter)
A hack where you change it to User Scope/String allows you to offer the user where to conenct to; you edit the conn string in My.Settings programmatically, in code at any time and every time from then on the app will connect to the new db
So dont be thinking conn strs have to be app scope///
I routinely change my conn strs to User scope AFTER i'm done changing the dataset (any attempt to edit a dataset with a user scoped conn str will break your design environment) and i offer the user a dialog on start.. do they want to conenct to test or live.. Whatever they choose, I change the conn str in My.Settings before i start accessing data. This is cool
We put the DataSource into the exception we were throwing and low and behold it was still pointing to MY dev. Which then lead us to the setting type and at that point the exename.exe.config file was created and our connection string was pulled from that file and not from copy of app.config buried in some user's path.
OK, that's kinda the part that loses me a little, but yep.. whatever works.. I do occasionally hose out the user config folders and remove old app configs accumulated when things go weird, i'll watch for that one..
So, you've learned the value of putting max info into an error message eh?
Throw New Exception("Error connecting to db: " & ex.Message & " ConnStr in use is: " & My.Settings.COnnStr)
