adapter.fill and progress bar

  • Thread starter Thread starter Rain County
  • Start date Start date
R

Rain County

When I initialize my app, I put up a "splash" screen with a progress bar
while the app fills its datasets. The fill takes longer sometimes than it
does other times. Is there anyway to measure/determine the progress of the
fill operation? I wish to know this so that I can adjust the progress bar
to be more realistic.

(Currently, the time to fill the datasets can range from 5 seconds to 20
seconds, even though the dataset size dows not vary very much.)

TIA
 
The issue with a progressbar is - you need to know the max, before reading
the first row. And to find the count you need to first execute a select
count - which is not terribly cheap (but not as awful as executing a select
*). (Please see -
http://codebetter.com/blogs/sahil.malik/archive/2005/12/12/135586.aspx ).
Maybe a better idea is to just show a rowcount as an indication of
progress - but if you must show a progress bar - well yeah you can, but you
will need to execute two queries -

Regards actually showing it, you can do it using DataAdapter by tapping on
the RowChanging and RowChanged events of the DataTable.

Alternatively you can use a DataReader to show a progressbar as shown here -
http://codebetter.com/blogs/sahil.malik/archive/2005/08/15/130763.aspx

- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx
__________________________________________________________
 
Thank you very much Sahil,

If the RowChanged event will be triggered during the Fill operation, then
that is just the hint I needed. Using Select Count (*) rather than Select *
was also a good tip. I will be using MSAccess rather than SQL and the table
is not humongous, so it should work great.

Thanks again.

Phil
 
Way better is to use a worker thread for stunts like this - otherwise window
refreshing sucks...
 
Miha,
Way better is to use a worker thread for stunts like this - otherwise
window refreshing sucks...
Click to expand...
Do you mean instead of?

Can you show me an example, I am curious about that. I could never do it in
another way than this because of the fact that opposite to the Update the
Fill does not give any event during the fill.

An extra problem is that the backgroundworker is not in the UI and the
progressbar has to be showed.

However let us make it simple, I am really curious for your sample. (Can be
in C# no problem)

By the way, I will never use this because of all the other overhead. But
that I told in my message.

Cor
 
No time for sample,
- events raised from backgroundworker (which is not the only way to use
worker threads) are synchronized with the control backgroundworker is placed
on. Thus you don't need any special synchronization.
- perhaps it has some overhead - but the advantage is big: having a
responsive UI. The same could be said for windows - why does windows use
multithreading?
- even with using raw threads, the synchronization with UI is fairly simple

You might read Chris Sell's article on this topic:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnforms/html/winforms01232003.asp
 
Miha,

I know this subject, I have had in past (at least more than a year ago) many
discussions about this with Jon Skeet, who as it than seems to me, would use
multithreading for everything.

I have seen that Jon now becomes too in my opinion a little bit more
selective for that.

Which does not mean that as Jon, I see as well many places where
multithreading can be used to give shorter throughput time. However probably
can the effort for this be better used in making the proces of getting the
data and handling that quicker.

Mutlithreading cost forever more processingtime than singlethreading and
makes at least a program less maintainable, which is for me a very important
factor.

Just my opinion.

Cor
 
Cor Ligthert said:
Miha,

I know this subject, I have had in past (at least more than a year ago)
many discussions about this with Jon Skeet, who as it than seems to me,
would use multithreading for everything.

I have seen that Jon now becomes too in my opinion a little bit more
selective for that.

Which does not mean that as Jon, I see as well many places where
multithreading can be used to give shorter throughput time. However
probably can the effort for this be better used in making the proces of
getting the data and handling that quicker.

Mutlithreading cost forever more processingtime than singlethreading and
makes at least a program less maintainable, which is for me a very
important factor.
Click to expand...

Tell that to MS - they should have kept the DOS or at worst single threaded
OS!
 
Miha,
Tell that to MS - they should have kept the DOS or at worst single
threaded OS!
Click to expand...
Do you mean that you want this.

I don't agree with you, as I wrote in the message you are replying, there
are in my opinion many places where multithreading has a benefit. An OS (or
better multitasking/multiprogramming/multiprocessing) is one of those.

Cor
 
When I initialize my app, I put up a "splash" screen with a progress bar
while the app fills its datasets. The fill takes longer sometimes than it
does other times. Is there anyway to measure/determine the progress of the
fill operation? I wish to know this so that I can adjust the progress bar
to be more realistic.

(Currently, the time to fill the datasets can range from 5 seconds to 20
seconds, even though the dataset size dows not vary very much.)

TIA
Click to expand...

If you're using .NET 2.0 you can use the Progress bar in Marquee mode.
When you use that mode the bars squares in the bar oscillate from one
side to the other while the work is being done.


Otis Mukinfus
http://www.otismukinfus.com
http://www.tomchilders.com
 
Thats a cool idea :)

SM [snip]
If you're using .NET 2.0 you can use the Progress bar in Marquee mode.
When you use that mode the bars squares in the bar oscillate from one
side to the other while the work is being done.


Otis Mukinfus
http://www.otismukinfus.com
http://www.tomchilders.com
Click to expand...
Click to expand...

Thanks, Sahil.

It sure solves the problem of needing to know the number of rows
returned. My opinion has always been that you don't need to be
accurate as to the amount of work left to be done. The important
thing is to let the user know the operation is still active. It keeps
'em from clicking stuff to see if they did something wrong or lets
them know they're not frozen up.

Naturally we should avoid long operations, but sometimes that doesn't
work ;o)



Otis Mukinfus
http://www.otismukinfus.com
http://www.tomchilders.com
 
Back
Top