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