We could not find a straight forward mechanism for updating the connectionString for the Commands in the QueriesTableAdapter. Still a roundabout way is there.
We have a protected property "CommandCollection" for "QueriesTableAdapter" class. This CommandCollection holds all the commands inside the QueriesTableAdapter. So, we inherited a class "XQueriesTableAdapter" from "QueriesTableAdapter". Now our XQueriesTableAdapter can directly manipulate the connectionStrings of the commands. Look at the code below. We need to pass the needed connectionString to the UpdateCommandConnections method of XQueriesTableAdapter.
************************************
public class GlobalQueriesTableAdapter : QueriesTableAdapter
{
public GlobalQueriesTableAdapter()
{
}
public void UpdateCommandConnections(string sConnString)
{
foreach (System.Data.IDbCommand BBXCommand in CommandCollection)
BBXCommand.Connection.ConnectionString = sConnString;
}
}
}
************************************
To call it use
oXQuerySet = new XQueriesTableAdapter();
oXQuerySet.UpdateCommandConnections(sConnStr);
*************************************
In our project, this works well. But we can still use the normal TableAdapters for doing the kind of work which we do using QueriesTableAdapters. So we are changing our code: that means we are removing QueriesTableAdapters and instead use the TableAdapters. So the original question comes back. Why the QueriesTableAdapters exist. What we feel is for the simplicity. You just drag and drop a stored procedure into the xsd file, and you get a perfectly working command object. No need to configure anything further. So for newcomers, this may be the best option.
Hope this post helps somebody.
Sacher