>Mr. Zonneveld,
>
>Thanks you for your informative reply. The file sizes are OK.
>
>I'm more concerned with the possibilities of corruption. For instance:

Use FLUSH after saving changes to tables (that is, after TableUpdate()).

Also, it is safer to turn of write-cache on the hard disk, if possible.

>Should I plan to use the "update" verb exclusively when storing data from records changed in master file maintenance screens?
>
>Since the normal flow of information does not include multiple people working on the same record can I fearlessly use the "replace" or the "gather memvar" commands?

Use buffering. Optimistic row or optimistic table buffering are the usual options.

Do any changes fearlessly, with REPLACE or GATHER, or whatever. You can also have, for example, TextBoxes, which are directly bound (.ControlSource property) to a field.

If you use buffering, no changes will be saved until you issue TableUpdate().

You can undo changes with TableRevert().

>Do I need to impose locks across all records being updated or does Fox 7.0 and above do that automatically?

In the case of optimistic buffering, the record is automatically locked as soon as you try to save your changes. If another user made changes in the meantime, the conflict will be detected; with the default options of TableUpdate(), no changes will be saved.

Check the return value of TableUpdate() to see whether it was successful.

If it returns .F., use aerror() to check the reason. These can be manifold: trigger failed; update conflict (as explained above); uniqueness of index violation; among others.

>In parent/child tables (as in orders and orderitems) what is the quickest slickest Fox way to develop screens that work in tandem to update orders and items?

For quick access, with a parent-child relation, use a view with a parameter for the "child" part. A view is like a query, but the result can be saved back to the original table. A view is opened like any table with USE, so you can use the same code you use for tables, with few adjustments.

>I ask this because my experiment with the "one to many" option in the form wizzard yields a disappointing result. I know the users cannot leap to deciding wether they should be adding a "parent and a child" or just "adding a child". I'll get hundreds of calls on that if it is even accepted as an application.

The form wizard creates forms based on a primitive framework, designed more as a proof of concept than as a complete solution.

You should either use an existing framework - free and commercial versions exist - or build your own one.

>What do you do for those kinds of forms?

Personally, I like Visual Extend. Mere Mortals is quite popular; it won the prize (here in the UT) of the "best framework". These are commercial; the Codebook is available for free, I think.

Greetings,

Hilmar.