Yes, you can have an async remote views. But in reality it is less practical than it seems.
In most cases you still have to wait until the view is populated. And you cannot use the same connection for other views.

I agree with your suggestion to look for ways to improve the query speed. By making sure the right indexes are there on the database, it usually is possible to improve it.

Actually a SF client put in a support ticket today that one of the forms was taking way to long to open. Analyzing the query in question I quickly realized it was doing a table scan on a large table. Adding an appropriate index reduced the time to execute from 10 seconds to about 10 ms.

Walter,



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