 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / .NET Framework / ADO.NET / January 2006adapter.fill and progress bar
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 __________________________________________________________ > 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 [quoted text clipped - 6 lines] > > TIA 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 > 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 [quoted text clipped - 27 lines] >> >> TIA Rain, Here a sample how you can fill a dataset while a dataset is going to be filled, be aware that the total process by this will be longer. http://www.vb-tips.com/default.aspx?ID=49f2cff5-56ad-44fc-a4c6-fc0d5c470f53 I hope this helps, Cor Way better is to use a worker thread for stunts like this - otherwise window refreshing sucks...  SignatureMiha Markic [MVP C#] RightHand .NET consulting & development www.rthand.com Blog: http://cs.rthand.com/blogs/blog_with_righthand/ > Rain, > [quoted text clipped - 6 lines] > > Cor Miha, > Way better is to use a worker thread for stunts like this - otherwise > window refreshing sucks... 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/wi nforms01232003.asp SignatureMiha Markic [MVP C#] RightHand .NET consulting & development www.rthand.com Blog: http://cs.rthand.com/blogs/blog_with_righthand/ > Miha, > [quoted text clipped - 17 lines] > > Cor 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 > Miha, > [quoted text clipped - 13 lines] > makes at least a program less maintainable, which is for me a very > important factor. Tell that to MS - they should have kept the DOS or at worst single threaded OS! SignatureMiha Markic [MVP C#] RightHand .NET consulting & development www.rthand.com Blog: http://cs.rthand.com/blogs/blog_with_righthand/ Miha, > Tell that to MS - they should have kept the DOS or at worst single > threaded OS! 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 [quoted text clipped - 6 lines] > >TIA 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 >>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 [quoted text clipped - 15 lines] > 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 [quoted text clipped - 3 lines] >> http://www.otismukinfus.com >> http://www.tomchilders.com 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 Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.