Data Binding, Combo Boxes, and Related tables.

[Mycroft Holmes]

patzerFish wrote:

Dataset->DataAdapter->TableAdapter->TableAdapterManager relationship

Here, I believe, lies the cause of your problem. Once you start relying on the Adapters you are screwed, they are sufficient for simplistic solutions and most devs abandon them fairly early in their career. Move to a properly implemented DAL (or even better build one). A simple one is fairly easy and should only take a couple of days, you need the CRUD methods that service DATATABLES only, rarely should you be loading a dataset (implies multiple tables returned) from a procedure. Now you have your data in nice easy to use datatables or List<> you need to use BindingSource as the datasource for your controls, this will give you greater control over your UI. Note: This is a personal opinion, however I have been using this design successfully for many years.

Never underestimate the power of human stupidity RAH

[PIEBALDconsult]

10!

[Mycroft Holmes]

Thank you. I'm a little tired of repeatedly stamping on these bloody adapters, I'm tempted to write and article/rant just so I can link to it as a response to this type of issue.

Never underestimate the power of human stupidity RAH

[Luc Pattyn]

Hi Mycroft, I wish someone did, I mean an article, not a rant. And I wouldn't mind at all if you were the one. I would suggest a simple application with one or two DataGridViews showing some query results, and an add/edit mechanism with one or two Forms so one can add/modify the DB and see the results. These questions are indeed popping up all the time. How about a small company with employees and some company cars? I would do it myself, however I lack DB experience and authority. I am willing to contribute as a proofreader, I'll sure come up with some basic why&how questions. :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum

Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.

[Mycroft Holmes]

I actually have a small app that is part of my 'framework' love that word that reads the data structure. I could expand on that I suppose. My problem is that I know nothing about the adaptors and to be of any value the article should be able to highlight the shortcomings of them rather than just say this is the way you should do it. I think Dave Kreskowiak may be the person to go to for this, he seems to know an awfull lot about the adapters.

Never underestimate the power of human stupidity RAH

[Luc Pattyn]

I see your point. If adapters are irresistible but not really the right approach, it deserves explaining. But even then, the right way is what is most important. Let's see how others may react on this. :)

Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum

Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.

[Roger Wright]

How about a partnership - you and Dave - to write about the pros and cons of each approach? :-D

Will Rogers never met me.

[Mycroft Holmes]

I think I will start something and then ask Dave to contribute - I will take this to the correct forum.

Never underestimate the power of human stupidity RAH

[Roger Wright]

Cool! I'll be looking forward to seeing the result. I've learned a bunch from both of you, and appreciate your clear, informative presentation style. I expect it will be a great article! :-D

Will Rogers never met me.

[MSBassSinger]

I am a firm believer in not passing datasets (or recordsets) around as universal data objects. I create objects that represent the real-world object, and aggregations of those objects where it makes sense. Those objects may span more than one table, the the consumers of my objects have no knowledge of a database. For aggregation objects, I create a class that inherits from CollectionBase. That allows me to add a class within the aggregation class that inherits from IComparer so I can provide sorting capabilities. The aggregation class contains the code to handle CRUD, and to allow specifying a filter for querying. The class that is used for the objects (the item class) collected by the aggregation class inherits from IDataObjectBase. The item class has code to validate, indicate if any values have been changed, etc. That allows me to use both the aggregation class and the item class for objects that easily bind and can be found in VS's Data Source Explorer. In a few cases, where I need hierarchical objects, an aggregation class can also be a property within an item class. Yes, it takes more coding than passing around datasets, but it is more durable. Besides, once you have the first one coded the way you want, you can use it as a template for others, which reduces the coding time.

[patzerFish]

Thanks for the feedback! I have begun to implement my own DAL building the CRUD (create, retrieve, update, delete) methods - but I've managed to do it without using datatables, following the model I used in a project where I was using C# to MySQL:

    private static void executeNonQuery(String query) {
        SqlCommand command = new SqlCommand(query, Connection);
        try {
            openConnection();
            command.ExecuteNonQuery();
        } catch {
            throw;
        } finally {
            closeConnection();
        }
    }

    private static SqlDataReader executeQuery(String query) {
        SqlCommand command = new SqlCommand(query, Connection);
        SqlDataReader reader;
        try {
            openConnection();
            reader = command.ExecuteReader();
            return reader;
        } catch {
            throw;
        } finally {
            //connection left open because the reader is worked on elsewhere.
        }
    }

These methods are the core of the DAL class. Each other static method (create, retrieve, update, delete) uses one of these two methods and pretty much has the responsibility of building a query string and passing it on. In the case of SELECT queries, a SqlDataReader is returned to be worked on. I haven't felt the need to push this data into a datatable, since it's fairly easy to just move this data into a data object or List<> of data objects. It will require more work on the side of binding data to form controls, but I think I prefer having more control over what is going on anyway. Thanks again for your quick response!

[underclocker]

I tried nHibernate once. It was a bit of a pill to get used to but once I did, I found that it really helped me in the whole binding and persisting work. It doesn't fit with my current work of real time processing ( well it would for system configuration and settings ) but otherwise I would use it all the time.

[Mycroft Holmes]

Excellent start, however you need to be aware the datareader lock the connection and should be consumed and disposed of ASAP, passing a datareader is asking for problems. For this reason I use datatable.fill. It uses a datareader under the hood but leaves you with a disconnected datatable as a result. Also I do not make my DAL class static, I often connect to multiple databases. I do have a static class that hold the main copy of the dal but I often create additional copies for specific connections. I have a single generic method that moves a datatable into a List<> of the object. I also have a UI helper class that binds a List<> to a form, naming discipline is required. If you send me an email I will send you a copy of the DAL class.

Never underestimate the power of human stupidity RAH

[Mycroft Holmes]

You use a more advanced structure than I do :-O as I use a List<> when coding for the web and datatable for winforms (I like the datagridviews native sorting support for datatable). You should do an article on your structure, I'd be interested in seeing it as I am always open to new and better ideas.

Never underestimate the power of human stupidity RAH

[MSBassSinger]

There are times I just use List<> or Dictionary<> when I don't need anything more than that. The main reason I use what I described is that 1) I want to encapsulate the CRUD operations at that level so the item classes are lighter weight, and 2) I want to provide other functionality than I get with List<> or Dictionary<>. I could, and have, used factory classes, but for some reason I am partial to strong encapsulation.