TableAdapters and maintaining state?

[Brett Romero]

I store my server and database names in a static class that all
libraries use. Using a config file, I can switch from test, staging,
or production servers easily.

I like what TableAdapters are generated by VS.NET 2005 do. It seems
most everything is there for you. However, because the TableAdapter
controls everything, I'll have to go to each and change the connection
string when I want to switch servers. Or, am I missing something?

Are TableAdapters a good idea for loading non UI objects? In other
words, creating .NET instances of database tables. These objects may
interact with other non UI or UI objects.

Thanks,
Brett

 

[Dave Sexton]

Hi Brett,

I store my server and database names in a static class that all
libraries use. Using a config file, I can switch from test, staging,
or production servers easily.

I like what TableAdapters are generated by VS.NET 2005 do. It seems
most everything is there for you. However, because the TableAdapter
controls everything, I'll have to go to each and change the connection
string when I want to switch servers. Or, am I missing something?

You can change the value of the settings property instead:

Properties.Settings.Default["LocalConnectionStringName"] = "new conn string"

Note: it has to be done using the indexer, not the property.

I like to use conditional compilation for this:

#If !DEBUG
Properties.Settings.Default["GlobalConnectionString"] =
Properties.Settings.Default.ReleaseConnectionString;
#endif

Are TableAdapters a good idea for loading non UI objects? In other
words, creating .NET instances of database tables. These objects may
interact with other non UI or UI objects.

A table adapter connects to your database, retrieves a single result set and
fills the corresponding DataTable in a Typed DataSet. You can use the filled
DataTable however you'd like. Bind to it from UI elements or pass it to
business objects for processing - It's your choice.