Refilling dataset without changing context

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

Cor
Sun Feb 03 23:48:11 CST 2008

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

"John" <John@nospam.infovis.co.uk> schreef in bericht
news:ujRVJDtZIHA.4476@TK2MSFTNGP06.phx.gbl...
> 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
>
>
>
>
>
>
>

Jack
Mon Feb 04 00:24:46 CST 2008

On Mon, 4 Feb 2008 01:53:48 -0000, "John" <John@nospam.infovis.co.uk>
wrote:

>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?

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.

John
Mon Feb 04 08:44:30 CST 2008

This must be a very common scenarios.What do other people do to achieve
this?

Thanks

Regards

"Jack Jackson" <jjackson@cinnovations.net> wrote in message
news:uebdq3t7d5its5c5v5vg5sp27bkujo1mn5@4ax.com...
> On Mon, 4 Feb 2008 01:53:48 -0000, "John" <John@nospam.infovis.co.uk>
> wrote:
>
>>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?
>
> 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.

John
Mon Feb 04 08:44:51 CST 2008

Fine, but what is the solution?

Thanks

Regards

"Cor Ligthert[MVP]" <notmyfirstname@planet.nl> wrote in message
news:B6BBF835-5A42-4689-BC3F-B59B500EBCED@microsoft.com...
> 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
>
> "John" <John@nospam.infovis.co.uk> schreef in bericht
> news:ujRVJDtZIHA.4476@TK2MSFTNGP06.phx.gbl...
>> 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
>>
>>
>>
>>
>>
>>
>>
>

Jack
Mon Feb 04 11:25:48 CST 2008

I rarely have a large number of records in a datatable, so refreshing
doesn't take a noticeable amount of time.

On Mon, 4 Feb 2008 14:44:30 -0000, "John" <John@nospam.infovis.co.uk>
wrote:

>This must be a very common scenarios.What do other people do to achieve
>this?
>
>Thanks
>
>Regards
>
>"Jack Jackson" <jjackson@cinnovations.net> wrote in message
>news:uebdq3t7d5its5c5v5vg5sp27bkujo1mn5@4ax.com...
>> On Mon, 4 Feb 2008 01:53:48 -0000, "John" <John@nospam.infovis.co.uk>
>> wrote:
>>
>>>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?
>>
>> 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.
>

Andrej
Wed Feb 06 01:10:22 CST 2008

Hi John,

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

Andrej

John
Wed Feb 06 11:52:54 CST 2008

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


"Andrej Tozon" <andrej.tozon@gmail.com> wrote in message
news:f8ac25e6-e60a-48a5-a889-9762351ef481@f10g2000hsf.googlegroups.com...
> Hi John,
>
> try calling your BindingSource's SuspendBinding() method before re-
> populating dataset, and ResumeBinding() after it's done.
>
> Andrej

Andrej
Wed Feb 06 12:40:34 CST 2008

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

On 6 feb., 18:52, "John" <J...@nospam.infovis.co.uk> wrote:
> 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
>
> "Andrej Tozon" <andrej.to...@gmail.com> wrote in message
>
> news:f8ac25e6-e60a-48a5-a889-9762351ef481@f10g2000hsf.googlegroups.com...
>
>
>
> > Hi John,
>
> > try calling your BindingSource's SuspendBinding() method before re-
> > populating dataset, and ResumeBinding() after it's done.
>
> > Andrej- Skrij navedeno besedilo -
>
> - Prika=9Ei navedeno besedilo -

Gregg
Thu Feb 07 11:00:02 CST 2008

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
--
Gregg Walker

John
Thu Feb 07 12:35:01 CST 2008

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

"Gregg Walker" <xyzzy@newsgroup.nospam> wrote in message
news:%23UjoiraaIHA.4476@TK2MSFTNGP06.phx.gbl...
> 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
> --
> Gregg Walker
>

Gregg
Thu Feb 07 14:54:50 CST 2008

> 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?

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
--
Gregg Walker

John
Thu Feb 07 15:12:21 CST 2008

Thanks. Makes perfect sense.

Regards


"Gregg Walker" <xyzzy@newsgroup.nospam> wrote in message
news:%23tYfvucaIHA.2000@TK2MSFTNGP05.phx.gbl...
>> 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?
>
> 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
> --
> Gregg Walker
>