Hi Ray,

> AERROR after the TABLEUPDATE reports 109, "Record is in use by another user."

In AFP applications we encountered error 108 (table is in use by another user) frequently, when AFP runs as a service and interactively with two different user accounts and the service version accessed a table using drive mappings defined in the interactive session. Switching to UNC paths solved that problem.

One workaround in your case could be to lock the header with RLOCK(0) before you try to update. By looping until you can place a lock on the header you should be able to serialize the TABLEUPDATE() calls letting only one user at a time save new records.