What you are referring to is the feature of record locking that the server does to make sure no two people are editing the same record. Directly, there is no way for a 2nd computer to force the 1st computer to relinquish the record lock. You can do things like make sure when scripts run, they end with a commit. You can have script trigger that commit records when exiting any field. And you can separate a single table into mutliple tables all related to each other so that if someone record locks something, it only locks up a portion of the overall record. You can have timer scripts that automatically commit records on a frequent schedule. And you can always use the admin console to kick off the first person from the database. You can make every field a prompt the saves and commits the record instead of working directly in a record. You can also have all the input fields be global fields and when someone wants to save a record, it converts the global fields to the permanent fields. And, of course, you can train staff to remember to commit records so that they are saved and not record-locked. These are some ideas... some of which are practical and some of which are not.
Thanks. Some great ideas. With the number of fields it can be a lot of work. I've given up on training the staff.
Agreed, and this is the difference between a database quickly designed for single user verses one where a lot of development work was put in the schema and scripts to make it work well for multi-user access. None of these things to make it multi-user friendly will be appreciated by the end user and they take a lot of time and effort to design and plan. But that is the difference between any old database and one designed for multi-user enterprise environment. Sometimes you can update the current system and sometimes I have had clients just start everything from the ground up. Both ways have their pros and cons.