>>>>A recent thread talked about performance of opening a form when the form uses views of tables from a network drive.
>>>>A suggestion that came up in order reduce loading time was to set NoDataOnLoad = .T. for each view.
>>>>
>>>>What if the form is based on tables. Is there a way to optimize the loading of the form?
>>>>I have a form that needs 12 tables and it takes approx. 9-10 sec to load when my data is on a network drive.
>>>>
>>>>I took a look to DataEnvironment.OpenTables method and AutoOpenTables property. Can we do something more efficient?
>>>>
>>>>Thanks
>>>>Claude.
>>>
>>>Claude,
>>>
>>>One way is to open ALL your tables in the default session of your app. Then in your private datasessions for each form VFP uses a USE AGAIN format which is quicker. This puts the heaviest time burden when the EXE starts rather than when each form starts.
>>>
>>>A second way is to load your most elaborate forms when the EXE starts, but HIDE() them until they're needed.
>>>
>>>HTH
>>>Barbara
>>
>>I have the same situation as Claude in a couple of my forms, (one uses 8 tables and 7 views) and attempted to speed things up by opening all of my tables in my startup code. I found that the time difference in form load time was negligible, but now (obviously) the app took a lot longer to load. I used the Stonefield Database Toolkit's openalltables method at the beginning to open the forms. I have since reverted to only opening tables in the DE. Any other helpful ideas, or insight as to why my performance didn't improve with this strategy would be much appreciated.
>>
>>Erik
>
>
>Erik, with 7 views, you're running a LOT of SQL code. This is not speeded up by pre-opening tables, and I imagine that's the heaviest time-slice. Have you tried setting no-data-on-load for each view (or else it will load data twice), and even not loading a view until the page using it is activated the first time?
>
>HTH
>Barbara

All of the views on the form in question are parameterized views, so they are set to nodataonload = .F. and REQUERIED only when needed. There are 3 seeks and 1 requery in the refresh event of the form, but the funny part is, the form takes a long time to open even for editing. This would seem to suggest that the chunk of time being taken is the form just finding the tables in the first place. This problem was still evident (though not nearly as much so) when the test data resided on my machine and not the server. As of now, I have resigned to living with the problem as the price I'm paying for a robust and complex form.