John, you seem to have plenty of advice on (1) and (2)....


>I would be grateful for tips to help me solve the following problems:-

>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?

No, if you don't need the NAME to refer to or LINKED to relate a form to another then don't use them. The problem with objects not released from memory is not the FORM object but objects added to the form during run time.

>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?

Surely there should be, but there isn't. EVERYONE complains about this. There are several ways around it, but the most frequently used is to re-set the DBC in the BeforeOpenTables event.

Another way (most useful when everyone is using the same drive mapping) is to have a 'live' copy of the source code in the folder/drive where your app is being run. Then just copy the new code do a build when necessary. If your data tables (DBC and tables) is not in the project you can compile to another name even while users are running the program.

HTH
Barbara