Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
How to implement a progress bar while running a remote v
Message
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
01680151
Message ID:
01680168
Views:
40
>>>I've had the problem when hitting a giant Oracle backend that had a kazillion records. I created a modal form that played a video, ran it before the requery started and closed it after the requery completed. In my case it was pretty simple to do because I had a classlib I wrote that did all the requerys, updates, etc. so only had to add it in my code in one place.
>>
>>I hear what you are saying, but I'm still having trouble understanding how much that gains. In any kind of n-tier environment, all that's demonstrating is that the client end (whether it's a FoxPro form, a web page, a winform, etc.) hasn't choked. If the query takes well more than the expected amount of time, I don't believe there's any ability to have async communications between the database (through a remote view) back to the client. (If I'm wrong on that, I'll stand corrected)
>>
>>I'm back to the original point, if 4-5 seconds is too long and a "you'll just need to be patient for 4-5 seconds" is not an acceptable statement to make to the users, I'd be looking at ways to improve the process.
>>
>>Then again, I have Verizon FIOS with 1 gigabit per second up and down, and there are times when I sign onto my bank that it takes 4 seconds to connect.
>My rule of thumb is that if there will be delay at all (more than sub-second) I display something to let the user know that something is happening.
>However, you're correct about looking at improving the process.
>- Inefficiencies can sneak in over time
>- New, more efficient, methods might be available

Ture -- but it all depends upon the backend. I have stuff that is querying bunch of tables with over a billion records in them -- so it's going to take a sec or two no matter how well the indexes are designed and database tuning is done. Of course this is not the norm - looking for network slowdowns, proper indexes in backend, and how much data you're pulling should for sure be looked at first. Once those are exhausted and query takes over 1 second.. then it's time to find a way to let the user know it's working and the app hasn't hung.
ICQ 10556 (ya), 254117
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform