Guidelines for periodically refreshing the DataSet RRS feed

  • Question

  • Hello,


    I have a question regarding refreshing DataTables in a typed dataset with the goal of minimizing concurrency issues.


    In this situation the application uses forms with objects bound to a BindingSource which in turn have as their dataSource a table in a typed DataSet.  A form typically loads its dataset tables on the form's load event.


    From what I gather, in an application where user's need the dataset to be regularly updated with background dbms changes, periodically calling the tableadapter fill method is the standard approach.


    In my case, my project has multiple subapplications or forms, some of which are based on a single datatable while others are based on two or more related datatables.


    Unlike the initial form load fill of two related tables, where the master table is loaded first, the detail second, the re-fill of two related tables poses complications because of the key constraint.  To deal with this, for lack of being able to think of anything more clever, I am simply doing a clear on the datatables then an immediate subsequent fill.


    To package this together and make it as transparent to the user as possible, any manual save (to the dbms) operation performed by the user will actually kick off a Save-Clear-Fill sequence.  I have added a bit of code to ensure that the user is returned to the same datatable row once the datatable(s) are reloaded.


    I have two questions;


    1.) Is something along these lines pretty much the norm for accomplishing dbms to dataset refreshes?


    2.) The above raises the question of how does one ensure that refreshes happen with more certainty/regularity than having the user periodically click Save.  Ideally I suppose one could set up some kind of timed refresh or short of that, using trigger points like the form receiving focus or even certain form navigation events.  Are there any 'best practice' guidelines for dealing with this matter?


    Thank You for any assistance you might offer,




    Monday, April 7, 2008 2:17 PM

All replies

  • SqlDependency Class might help you

    Monday, April 7, 2008 4:24 PM
  • Giorgi,


    Thank you for the reply - I did a little investigating on the SqlDependency class and it looks quite promising.


    Do you know offhand whether this feature has been upgraded/streamlined at all from .net framework 2.0 to 3.5?


    Thank You,


    Tuesday, April 8, 2008 12:31 PM
  • There have been no updates to the SqlDependency between 2.0 and 3.5.  Also, if this is a client application you need to be careful of the number of refreshes that can occur from users of the application.  Generally SqlDepedency is a good middle tier solution that everyobdy is hitting for their data.  Also, you don't want to use SqlDepdency when there are a significant number of changes to your backend becuase of scalability issues. 


    Also, there are a number of ways to handle the concurrency issues you are talking about and refreshing the dataset with updated values is one way to do that.  You could also handle concurrency violations through logic in either stored procedures or in update failures. 




    Wednesday, April 9, 2008 12:43 AM
  • Dale,


    The situation that you are describing is definitely a mainstream scenario for DataSet. Your approach is a good way to handle refreshing the DataSet, however, another option to leverage the Merge functionality.


    Once you initially load the data into your Typed DataSet, you can have some other process that peroidically queries the Database and loads the results into a new DataSet (Typed or not). Once you have this updated data, you can merge the two DataSets, thus maintaining both your user's edits and the changes from the database. There are options on the merge method that allow you to define how conflicts are resolved.


    In terms of how to actually implement such a design, I would recommend a background worker thread to load the refreshed DataSet from the database. However, always make sure that when you actually merge the contents that you do it on a single thread. The DataSet is not thread safe for writes, and you can easily corrupt your data (sometimes silently) if you update a DataSet from multiple threads.


    Let me know if this makes sense, and if you have any other questions.




    Thursday, April 17, 2008 11:37 PM