but i think that "latency" is most used replication to justify a lot of problem that i have meet in rsWeb.
Latency/bandwidth is the most likely reason why a large data transfer that works over LAN would fail over WAN/Internet.
but i think/believe that webApp must no lock/stall if the operation (like retrive some records) employ long time...
Breaking tasks down into pieces to avoid locking up the UI, desktop or web, is not something the compiler can automatically do for you. You have to look at your code and decide how to do that. In this case it's pretty easy. Do one or both of the following:
* Display subgroups of records, say 100 per group, and give the user some way to navigate the groups.
* Load the WebListBox using a WebTimer.
I think that when %CPU is hight the webApp can be slowed (like locked) but when %CPU back to normal level (in this case the sub that retrieve records and fill webListBox has terminate his execution) the webApp must come back to respond and not result locked/stalled.
the latency must no lock/stall my webApp.!!!
WAN speeds are a fraction of LAN speeds, and the client side framework can't do much until it has all of the data.
Then i can create code for manage this problem but this is not a recognized/documented problem of rsWeb edition...