Hi John,

In your situation I would try to find the place first which is causing the slowness. Use the Coverage Logging available in DEBUG by which you will be able to find which code is slowing things down.

>I would be grateful for tips to help me solve the following problems:-
>
>1) I have an multiuser VFP5 app working on a LAN. Typically users see a full screen grid browse of records from a filtered dbf and double-click on a row to edit the record on a sumperimposed form window. The problem is that with more than about 5000 records it is REALLY slow getting into the edit form. The full-screen grid is fine. Both forms use private data sessions but the grid opens files with USE and the single-record form opens files using a Data Environment. The single-record form typically has several of .dbfs open, but the full screen browse only one.
>
>2) Users can right-click on the grid to add/amend/view/delete/change order/change filter. This uses the user-configurable shortcut menu object in Tasmanian Traders, not bog-standard shortcut menues. This also is really slow coming into action when the dbf size is above 5000 or so records.
>
>3) Am I asking for trouble not using the NAME xyz LINKED parameter when DO'ing FORMS? I know the object may not be released from memory but what implications does this have in real life?
>
>4) In the situation in 1) above on my development PC a test setup uses the correct database in the grid (I SET PATH at app start) but uses my development database in the single-record form. This appears to be because the DBF definitions in the Data Environment are hard coded to the full development directory path. Surely this should be a relative path? Is there a realistic way to prevent this happening?