Dear Bonnie,

Thank you for your extensive answer. I had "browsed" through your blog, but did not get to the links that you pointed me to here. When I grow up, I want to master this material, but at this stage, my c# reading is shaky at best and my vfp->.net metamorphosis is far from completed (but believe me, I'm working on it).

My reading of the connection string from a local "Ini" kind of a text file is just for configuration purposes. In production, the path to the db might be different from the one in the development environment. (I am working on an access db for the time being, but when I grow up ...).

Thanks again and kind regards,

Marc


>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