Thanks Roger
I have been using this approach up til now but I recently wasted time looking at why an app worked fine in development and not in live envionment only to find I'd forgotten to include the redirect on a newly added table.
I do not understand why Microsoft allows us to change so many parameters and system attributes in VB.NET but decided we're not to be trusted changing connnectionstrings!!
Ian
Main Topics
Browse All Topics





by: SanclerPosted on 2006-08-19 at 16:59:37ID: 17349636
Ian
ng property of each TableAdapter.
Connection String = "<myUserConnectionString>"
The only way I've found of doing this is via the .Connection.ConnectionStri
The Wizard embeds the ConnectionString as an Application Setting. Although it can then be altered, I have only been able to do this at design time. I have not been able to find any way of getting the Wizard to save it as a User Setting, or to retain amendments I made to the designer code to try to change it to a User Setting. It's all done in the background - with Designer code and Private properties and methods - and fiddling with those either causes crashes or doesn't persist through a Build.
But there is a "loophole". Each TableAdapter's .Connection property is declared, in the DataSet.Designer code file (in the DataSetTableAdapters Namespace), as Friend, and with a Set as well as a Get. So a sub on these lines for each TableAdapter (or one sub with a number of lines covering each of them)
Private Sub changeConnection()
myTableAdapter.Connection.
End Sub
called before any use is made of them allows the default, Application Setting value/s to be overwritten. As the only access I can find is via the TableAdapter it means that the change (probably the same change) has to be made for each. But I think this sort of "workaround" is essentially the line that you'll have to take. Where and how you store and retrieve the value/s that you use for <myUserConnectionString> is up to you.
I'll be interested to hear if anyone else has found a more "pukka" approach.
Roger