Not completely data "access" issues.
Peter said:
1. Connection String needs to be customizable by users during runtime.
This is not a major issue, as you can use a singleton for connection and
change at the user's whim. If you want to save back the connection string,
it is a bit more of an issue if you are using web.config alone, but it is
not insurmountable, as you can add auxiliary files with your own config
information.
2. Source of Connection String can be changed programmatically.
Source of connection string? You mean sometimes it comes from config,
sometimes from metadata tables, sometimes from XML files, sometimes from
user input? Or, do you mean you need to be able to change the connection
string using code?
If the former, set up a factory pattern with different options that are
available and you can then use the correct factory based either on config or
user input.
If the later, shy away from TableAdapters in 2.0, unless you want to edit
the code created to allow you access. In 3.5 (VS 2008, formerly Orcas) the
field opens up.
3. Tables can be modified by users.
To alter actual data tables, use SMO.
4. Use table adapters or use data adapters
Table Adapters are cool, but a pain for the flexibility you require during
run time.
5. How to update all data tables for all datasets with changes in a
Windows Form without specifying dataset?
I am not sure I understand this. Any time you open a table, you will have a
dataset. As long as you know which database you are currently using
(singleton config information?) and have the dataset, you can fire off an
update. Am I missing something?
--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
http://gregorybeamer.spaces.live.com
Co-author: Microsoft Expression Web Bible (upcoming)
************************************************
Think outside the box!
************************************************