Hi Heiko;

  In most of the Apps where I have seen this issue, were easily solved by:

1) Only retrieve the DS's when they are needed (just in time processing)

2) Move the DS retrieve's to Shared Object's (lazy retrieve's - aka background)

3) Move the DS retrieve's to POST Open / Constructor events where possible.

4) Remove sorting and filtering DW commands until after the retrieves

5) Move initial data sorting to the DBMS side from PB's DWOs.

6) Use a DB "native" driver where possible.

7) Use a "RetrieveAsNeeded" approach and only complete the full retrieval on a POST Open/Close event or better yet - only when the full result set is absolutely needed in the processing cycle.

8) Optimize your SQL (ie: https://support.quest.com/sql-optimizer-for-sql-server/10.1.2).

Food for thought.  ;-)

Regards ... Chris

Maybe a crazy approach, depending on how much effort this would cost:

Try getting all the information you need on a single datastore, maybe using VIEWS or UNION ALL.

You can add a type column to the UNION's Selects to identify the difference between the ds's you had initially.

You'd only have to do one retrieve and suffer the latency once.

Client/server architecture programming practices typically don't consider latency of network connection because it is meant to be used in LAN not WAN.  The "best practice" way these days to solve your issue would be to move your business/data logic into REST APIs using PowerScript Migrator and then call the REST API from your PowerBuilder UI using the RESTClient object.  Basically, you are moving the ping-pong you talk about from your client to the server so ping pong happens on low latency connection.