Generic TableAdapter reference RRS feed

  • Question

  • Hi,

    Is there a way of making a generic TableAdapter reference for TableAdapters created in the DataSet Designer?

    I would like to be able to have a generic reference to a TableAdapter on an ancestor class that is instantiated on a descendant class (i.e. customerTableAdapter). Or is there a better way to do it? I would like to be able to do something like:

    GenericTableAdapter.Update (GenericDataSet, GenericTableName);

    Can this be done?
    Wednesday, February 20, 2008 7:00 PM

All replies

  • Have you ever looked at the class definition of a table adapter?  BIG.

    What would be the generic type or types?  Types that replace which types?


    The designer does a rather impressive job of generating thousands of lines of code for a custom control on the fly.  Take a look at it.  Is that what you are trying to replace with a generic implementation?  There's more to it than just the one control.





    Wednesday, February 20, 2008 7:36 PM
  • Well, what I'm trying to do is somewhat re-create how datawindow objects and datawindow controls work in the Datawindow .Net world.

    I would like to be able to create base User Controls for Free Form input/output and Grid-like (DataGridView) input/output. A developer would inherit from these base user controls and drag either table columns on to it and create a free form user control or configure the properties of the DataGridView user control to associate a table to it.

    These user controls then could be dropped on inherited forms, such as a Search Form (inherited from a BaseSerachForm) and for the most part the form would be read to use. We did this in the PowerBuilder and it was easy (and doing it with the Datawindow .Net library from Sybase is pretty easy).

    So, am I attacking this in the wrong way?

    Wednesday, February 20, 2008 8:23 PM
  • So what does TableAdapter have to do with creating a simple DataGrid, or rather a DataGridView? 

    Will the user still be able to add columns or rows programmatically when you are done?

    Wednesday, February 20, 2008 9:14 PM
  • In the Datawindow world, the user interface is created in something called a datawindow object. It contains the SQL and design information. There is also a control called a datawindow control. It controls the datawindow object. So, it has methods for connection, scrolling, validating, adding, updating, etc. This datawindow control is then placed on a form and you can associate any datawindow object to it (the datawindow control). So, you can have developers that all they do is create the user interface (free form, grid, tabular, etc.) - the datawindow objects. They don't have to care about how it's going to be used.

    So, I could create a search form (that would have a coded datawindow control) that could be associated with any datawindow object (via a property setting) and the form would be ready to run.

    I don't see an equivalent of this in the Visual Studio world. If a developer is creating a free form user interface, he or someone else (from what I see) has to do coding to connect the pieces together. Correct me if I am wrong about this.
    Wednesday, February 20, 2008 9:33 PM
  • Even if there was 1000 000 lines of smart code generated by MS they still have made a BIG misstake of not, at least, implement some of the "main" public methods (e.g Update) so that we could treat TableAdapters in a more generic way, like passing them around and working with them through, lets say a proxy.



    Friday, October 24, 2008 9:10 PM
  • Have put one together once. I used a generic method and added constraints for class, new, IDisposable, which gave me the possibility of just providing the type of a certain TableAdapter and then I could create an instance where simple in my method, in a using-block. I also passed a datatable to the method which I then passed in as an argument to the Update method, which I accessed via reflection. The methodinfo, could be cached for the passed tableadapter type, in a static generic dictionary. Note! You will then have to make it thread safe.



    Friday, October 24, 2008 9:14 PM
  • I noticed that you have crafted a solution. I think I understand your problem. When the code is created in the code generator it all derives from Component. It doesn't derive from a DataAdapter or its interface. Each DataTable has its own DataTableAdapter, you want a common way api to use across all the adapters.


    First if you are using Visual Studio 2008, the code generation produces something called a TableAdapterManager. You can create all the adapters you use and call UpdateAll(DataSet ds) and it will run though all the updates and do these in the correct order.


    What you could also do is make something like a TableAdapterManager as well


    Another thing you could do is create your own interface,

    public interface IMyDataAdapter


    void Fill<T>(T table) :where T : DataTable

    void Update<T>(T table): where TBig SmileataTable



    It appears you have a solution anyway but maybe these are a couple other things you can look at.



    Chris Robinson

    Program Manager - DataSet

    Monday, October 27, 2008 5:09 PM