Testing app with Typed Datasets using Test & Production databases

[Guest]

I am using typed datasets in a forms application. I would like to use one
typed dataset to run my application against my test database. Then when I’m
ready to release it I would like to point the typed dataset to the production
database. (The schema will be exactly the same).

I don’t want to have to change the connection strings one datatable at a
time in the wizard. And I don’t want to have to create a production dataset
and test dataset. (Because the code will expect to be working with a
particular typed dataset) I would like to be able to make the change
without having to enter the dataset wizard.
Perhaps flip a switch in the app config file if possible. (But I will also
want to be able to perform the switch on datasets that reside in a separate
class library)

I experimented with editing the connection string in the config file but
the datasets appear to cache the connections strings. Even rebuilding the
assembly didn’t refresh the connection strings from the config file. I
noticed that if I browsed backward to the connection selection in the wizard
that the dataset would grab the new version of the connection string from the
config file on the next rebuild.

I am currently using one Typed data set for each database. (test MsAccess,
Test MsSql, prod MsAccess, prod MsSql) For read only operations I’m able to
populate the tables of one typed dataset from the other typed datasets using
the myTypedDatatable.merge(SourceTable). But this is horrible for code
readability and the application and does not even permit testing of
insert/update operations.

I think I must be missing something…there has to be a better way of doing
this…

Thanks in advance,

-Jeff

 

[RobinS]

Are you using the DataSet Designer to create your datasets?
If so, it stores your connection strings in the <Settings> for your
project.

If you're using VB, you can double-click on "My Project" (the
one with the dataset defined) to see your project properties.

Under the SettingsTab, there should be a connection string.

If you're making your own typed datasets, you can store the
connection strings there anyway (there's a type for ConnectionString).
Then you can access them by saying My.Settings.whateveryoucalledit (in VB).

Dim cnn as New SqlConnection(My.Settings.CustomerConnectionString)

Then you can change them in one place, and they will be
used throughout your app.

You can also programmatically update the <Settings>, and give
yourself the option to toggle which database you run against.

If you're using C#, there's probably a way to do the same thing,
but I don't have the details.

Robin S.
(VB2005)

 

[Guest]

Robin,

Thanks for such a quick response. After reading your response I realized
that I hadn’t successfully overridden the connection string in the dll
app.config in my application app.config.

Unfortunately it doesn't appear to work across providers. I can point
typed dataset originally set up with the System.Data.OleDb provider with
other access databases by changing the connection in the app.config file.
However when I try to change the connection to point to am MSsql database
with the System.Data.SqlClient provider it throws an exception. It shows
that the code auto generated expects an oledb connection.

Is there anyway to get around this? Maybe through a more generic provider?
I know my query syntax has to be slightly different for the two providers.
Is there a tool to rebuild my data set for a different provider. That way I
would only have to maintain one copy of the dataset and I could auto generate
the other.

If anyone knows who to get around this I would appreciate it.

Thanks,

Jeff