Hi Ferdinand

As Chris has said, I'd be looking at the DWs and UO constructor events to see what they are doing. Given that you have over 70 DW which I guess are all retrieved in the opening sequence, if each one only took 0.065 of a second to retrieve then that would be your 5 seconds.

If the DWs are retireved in the open sequence of events that you can chaneg that to only retrieve on demand as the user selects the relevant tab.

It should be fairly easy but tediod to work through the events and speed it up.

I'd start with Chris's suggestion and set the tab properties to create on demand, that a very quick and easy fix and may well solve your problem. See option near the bottom of the image below.

Cheers

David

Most of the times, DB retrieval is what is slowest.

Run a database Trace on the application:

If you want to only check the SQL execution times of one window, then in the open event, disconnect and re-connect with sqlca.dbms = "TRACE ......."

From the same open, launch an event with POST to do the disconnect and re-connect without the TRACE keyword in the sqlca.dbms.

(of course this is just to run your test).

regards.

Hi Ferdinand;

   One of the big overheads in your description are Tab Controls and their Tab Page child objects. Many app developers need complex processing in these objects but fail to use "Create On Demand" option. The default is off which means that all Tab Pages and their child objects run their "constructor" events before the parent window' open event.

  The next area is the DataWindow objects and what each DWO is doing in their instance. Can some of these DWOs processing be delayed or optimized?

  User objects are another optimizing opportunity. Instead of placing the UO's on their parent objects at design time. Consider dynamically creating them only when needed using the OoenUserObject() command.

HTH

Regards .... Chris