Refilling dataset without changing context

  • Thread starter Thread starter John
  • Start date Start date
J

John

Hi

I have a winform db app that is "bound" to a dataset...via data adpater,
binding source and all that. As this is a multi-user app I need to refill
dataset from time to time so the newest data is available for user to view.
My problem is that I

a) do not wish the app to become unresponsive while re-fill is being
performed so need to do it as background task if possible.

b) do not want the record context to change for user so user does not notice
any disruption.

My question is, are the above possible? If so, how? If not what is an
alternate strategy?

Thanks

Regards
 
John,

Normally does the Refill in a normal situation not take that time (don't
compare it while debugging) that the user will notice it.

As it does, then even without reloading you would in my idea have a look
again to your design.

Be aware that every Background task cost you processing time, so keep track
that this background task does not take more throughput time then normal
receiving the data from the database. Background task are very well for
assynchronous processing. However, here the user has to wait until the data
is again fresh and therefore a part of the synchrounous process.

Cor
 
Hi

I have a winform db app that is "bound" to a dataset...via data adpater,
binding source and all that. As this is a multi-user app I need to refill
dataset from time to time so the newest data is available for user to view.
My problem is that I

a) do not wish the app to become unresponsive while re-fill is being
performed so need to do it as background task if possible.

b) do not want the record context to change for user so user does not notice
any disruption.

My question is, are the above possible? If so, how? If not what is an
alternate strategy?
Click to expand...

No matter how you refill the dataset, while it is refilling the user
will see effects in the bound controls.

It might be better if you have two datasets. Bind one to the
controls, then refill the other. When it is refilled switch the
binding.

I have no experience with trying to fill a dataset asynchronously and
don't know if it is possible.
 
This must be a very common scenarios.What do other people do to achieve
this?

Thanks

Regards
 
Fine, but what is the solution?

Thanks

Regards

Cor Ligthert said:
John,

Normally does the Refill in a normal situation not take that time (don't
compare it while debugging) that the user will notice it.

As it does, then even without reloading you would in my idea have a look
again to your design.

Be aware that every Background task cost you processing time, so keep
track that this background task does not take more throughput time then
normal receiving the data from the database. Background task are very well
for assynchronous processing. However, here the user has to wait until the
data is again fresh and therefore a part of the synchrounous process.

Cor
Click to expand...
 
I rarely have a large number of records in a datatable, so refreshing
doesn't take a noticeable amount of time.
 
Hi John,

try calling your BindingSource's SuspendBinding() method before re-
populating dataset, and ResumeBinding() after it's done.

Andrej
 
Hi Andrej

Thanks. Would it have any effect on user experience in that user's editing
at the time of dataset population will be lost for example?

Any idea if I can populate dataset as a background task without problem?

Thank again.

Regards
 
First of all, holding large amounts of data (which you don't really
need) in memory, is not such a good idea. I would really only
repopulate readonly data (used for comboboxes etc.), and never data
(tables), which user is currently editing.

Populating datasat in background is a valid option, but you'll have to
be carefully (again) as to when and how do you do it.

Andrej
 
Hi John -- This is a common scenario in many of our applications.

Our pattern for handling this is to use two datasets. One that is bound to
the UI control and one that is updated in the background. Let's call them
UISet and BGSet for our purposes here. Here's a brief description of the
different parts that are used to effect the updating of the UISet from the
BGSet.

1. Create a background thread that monitors for data updates. In some
cases we just set a timer and when it expires the BGSet is refilled. In
other cases we listen for UDP datagrams to let the background thread know
when it needs to refill the BGSet. You can use whatever method you desire
to determine the right timing for refilling the BGSet.

2. Create a delegate method on the main UI thread that can be invoked from
the background thread when a new BGSet is available.

3. When the BGSet has been refilled it Invoked the UI thread delegate.

4. UI thread delegate is then responsible for...

a. Save current context of bound controls (i.e. saving the position of
the the currently selected rows, etc.)
How you accomplish this will be dependant on the control you are
using to present the data.

b. Dispose the current UISet.

c. Assign the BGSet to the UISet.

d. Reapply the saved context to the bound controls so user does not
notice change in context.

We use ComponentOne FlexGrid controls with our bound UISets so saving
context means getting the current row for each grid and then setting the
current row back to that same value after the UISet has been updated from
the BGSet. You will obviously have to apply what works for the controls you
are using.

HTH
 
Hi Gregg

Many thanks for the detailed reply. I was looking for something like this.

Just one question; if the user is in the middle of an edit is that
information not lost when UISet has been updated from
the BGSet?

Thanks

Regards
 
Just one question; if the user is in the middle of an edit is that
information not lost when UISet has been updated from
the BGSet?
Click to expand...

Basically what we do is throw away the BGSet whenever the user is in the
middle of editing.

So I'll have some code that detects when an edit is started and finished and
update some global bool that will let the UI thread delegate know not to do
anything with the BGSet when an edit is in progress. The UISet will only be
updated when an edit is not in progress.

Also in the case where the process of rebinding the UISet to controls may a
short time you may conversely want to prevent editing while the delegate
method is actually rebinding the UISet.

Another way to handle this if you can't afford to ignore new BGSets is to
push new BGSets onto a stack when the delegate method is called and an edit
is in progress. Once any edit is finished you can check the stack for
entries and pop the last BGSet and rebind when one exists.

HTH
 
Thanks. Makes perfect sense.

Regards


Gregg Walker said:
Basically what we do is throw away the BGSet whenever the user is in the
middle of editing.

So I'll have some code that detects when an edit is started and finished
and update some global bool that will let the UI thread delegate know not
to do anything with the BGSet when an edit is in progress. The UISet will
only be updated when an edit is not in progress.

Also in the case where the process of rebinding the UISet to controls may
a short time you may conversely want to prevent editing while the delegate
method is actually rebinding the UISet.

Another way to handle this if you can't afford to ignore new BGSets is to
push new BGSets onto a stack when the delegate method is called and an
edit is in progress. Once any edit is finished you can check the stack
for entries and pop the last BGSet and rebind when one exists.

HTH
Click to expand...
 
Back
Top