Hi Marc,

>Your critique of TableAdapters caught my eye. I understand (very little at this point in time as should be obvious) you object because it handles the connection.

Not totally ... I don't object because it handles the connection, I object because TableAdapters get generated in the Typed DataSet Designer.cs file. The DataAccess does NOT belong there! TableAdapters are not a "best practice" in my opinion. You can have Typed DataSets without using TableAdapters, but since VS2005, Microsoft has made it more difficult to do (some extra steps involved).

I've written a blog post about TableAdapters, http://geek-goddess-bonnie.blogspot.com/2009/09/tableadapters-are-crap.html

Here's an excerpt from that blog post:

One of the problems that I see with the TableAdapter is the inflexibility. The generated class tightly-couples the DataSet to the database, and I don't believe that DataSets should be used that way. I use DataSets simply as a data transport mechanism. My DataSets know nothing about where their data comes from, nor should they.

OK, technically speaking, the DataSet class doesn't know about where its data comes from, just because I'm using a TableAdapter. But the fact the TableAdapter gets generated inside the DataSet.designer.cs means that the DataSet DLL is no longer database agnostic, and that's a very bad thing for correct client-server / SOA architecture. There is no more separation of layers when done this way. The DataAccess classes should be a totally separate layer with their own DLLs, just as the DataSets should live in their own DLLs.

That post also contains a link to another of my blog posts (http://geek-goddess-bonnie.blogspot.com/2010/04/create-xsd.html) about how to go about creating an .xsd and generating the Typed DataSet without all the TableAdapter junk getting put into it.

Now, granted, if you don't use TableAdapters, there are extra things you need to take care of in a DataAccess class (as I mention in my 3-part series) for using the DataAdapter instead, but you are in better control and don't run into the problems that are inherent with TableAdapters.

Here's my 3-part DataAccess series:

http://geek-goddess-bonnie.blogspot.com/2009/09/dataaccess-part-i.html
http://geek-goddess-bonnie.blogspot.com/2009/10/dataaccess-part-ii.html
http://geek-goddess-bonnie.blogspot.com/2009/10/dataaccess-part-iii.html

Each post adds extra complexity to the Data Access classes, but more flexiblity. However, even just the information in the first post is enough to get you going and is a great starting point for those wishing to have more control over their Data Access (and to move away from using those confounded TableAdapters)

>I am setting the connection string at startup as follows (csName is set from a textfile)
>

>        Dim config As System.Configuration.Configuration = ConfigurationManager.OpenExeConfiguration(ConfigurationUserLevel.None)
>        Dim csName As String = "b040.My.MySettings.b040_beConnectionString"
>        Dim csSection As ConnectionStringsSection = config.ConnectionStrings
>
>        csSection.ConnectionStrings.Remove(csName)
>        Dim csSettings As New ConnectionStringSettings(csName, cConnString)
>        csSection.ConnectionStrings.Add(csSettings)
>        config.Save(ConfigurationSaveMode.Modified)
>

>
>I don't know why, where or what, but I am aware that this must sound pretty blasphematory to you.

Actually, there's nothing wrong with using the config file for connection strings ... that's what they're good for (although, I don't know why you're also getting an additional string from a textfile ... just put it all in the config file to begin with). The point is that you actually use the ConnectionString when creating a connection which should only be done in a separate DataAccess class ... not in the UI portion of your application.

~~Bonnie