.Net 2.0 Table Adapter best practice
-
Hello, I was hoping someone could give me a bit of information on the way I should be creating / handling my table adapters. I have a persistant business object that is managing a number of database calls using a lot of different table adapters. The question I have is what the best practice is for creation of these table adapters. Is it better to persist a reference to each of my different table adapters over the life of my business object (i.e. create them all once, store them in class variables, then dispose of them all at the end) or is it better to create them as they are required (i.e a new table adapter created for each function call). If someone could give a bit of an insight into what a table adapter is doing in terms of the connections created for it during instantiation that would be most helpful in helping me decide the most efficient approach. Thanks for your help, Adam
-
Hello, I was hoping someone could give me a bit of information on the way I should be creating / handling my table adapters. I have a persistant business object that is managing a number of database calls using a lot of different table adapters. The question I have is what the best practice is for creation of these table adapters. Is it better to persist a reference to each of my different table adapters over the life of my business object (i.e. create them all once, store them in class variables, then dispose of them all at the end) or is it better to create them as they are required (i.e a new table adapter created for each function call). If someone could give a bit of an insight into what a table adapter is doing in terms of the connections created for it during instantiation that would be most helpful in helping me decide the most efficient approach. Thanks for your help, Adam
Since each creation of a new table adapter will require one or more network round trips to populate the date, it is better to persist a reference as long as the data contained is not likely to become stale rapidly. The trade off is that keeping populated table adapters around can consume a lot of memory if the tables are large.
-
Since each creation of a new table adapter will require one or more network round trips to populate the date, it is better to persist a reference as long as the data contained is not likely to become stale rapidly. The trade off is that keeping populated table adapters around can consume a lot of memory if the tables are large.
You seem to be inferring that each instance of a table adapter stores the data from the table in the application. Are you certain this is correct as I assumed that data was only retrieved once the Select function of a table adapter was called in order to fill a data table object? (It is possible that my orginal message was not clear enough and you thought I was referring to data table objects rather than table adapters) I always assumed that table adapters stored connection details for the appropriate database object - these are the resources I was hoping to find out about so that I can ensure my application is not leaving connections open inappropriately or unnecessarily hammering the database.
-
You seem to be inferring that each instance of a table adapter stores the data from the table in the application. Are you certain this is correct as I assumed that data was only retrieved once the Select function of a table adapter was called in order to fill a data table object? (It is possible that my orginal message was not clear enough and you thought I was referring to data table objects rather than table adapters) I always assumed that table adapters stored connection details for the appropriate database object - these are the resources I was hoping to find out about so that I can ensure my application is not leaving connections open inappropriately or unnecessarily hammering the database.
I'm not going to comment on Table Adapters as I don't use (like) them very much. However, you may want to look at using Query Analyzer to see what is happening with your connections (and queries). This tool is invaluable.
the last thing I want to see is some pasty-faced geek with skin so pale that it's almost translucent trying to bump parts with a partner - John Simmons / outlaw programmer
Deja View - the feeling that you've seen this post before. -
You seem to be inferring that each instance of a table adapter stores the data from the table in the application. Are you certain this is correct as I assumed that data was only retrieved once the Select function of a table adapter was called in order to fill a data table object? (It is possible that my orginal message was not clear enough and you thought I was referring to data table objects rather than table adapters) I always assumed that table adapters stored connection details for the appropriate database object - these are the resources I was hoping to find out about so that I can ensure my application is not leaving connections open inappropriately or unnecessarily hammering the database.
NamelessParanoia wrote:
ou thought I was referring to data table objects
Yes, I was confused... Each call to Myadapter.Fill or Myadapter.Update will cause a network round trip. If you open the connection before calling Fill, then the connection will remain open, otherwise it is opened and closed for you. The data (and schema information) gets stored in the datatable/dataset.