When Not to Lock Parent Records
In some specific situations, you might want to disable the locking of parent records at commit time. You can disable locking for one relationship, or for all relationships.
To minimize potential lock conflicts, the Rules Engine performs a minimum amount of locking. For restrictive checks where locking is necessary, the main strategy is that records are locked no sooner than at commit time, and that commit follows as soon as possible after the lock.
As an example, consider manually entered foreign key values (as opposed to values retrieved from a lookup window). At group validation time, just after field validation, these foreign keys are checked for the first time. This is to prevent the user from having to wait until commit.
The parent record is not locked until commit. This lock is also a second check: if the parent record cannot be locked, then the integrity of the entered foreign key value is no longer guaranteed. Between the lock and the actual commit, all restrictive multi-record constraints that need the parent record are evaluated.
In spite of all this, locking in this way may prove unacceptable to your organization. It does mean that two users cannot concurrently add a new child to the same parent.
When to use
There may be reasons why this check is unnecessary. For instance, the parent table is protected against any data manipulation other than INSERT, or a parent table contains relatively few records with many children. In this case, users changing or inserting unrelated child records could lock each other out. When the parent tables are not subject to many changes it may be better not to lock the parent. In such cases, you may decide the lock is unnecessary and:
To prevent locks on parent records for the entire application:
The Property Inspector for the application is opened.
Only set the Lock Foreign Keys property to No if you are absolutely sure this will not harm the integrity of the data. This property does not apply to Sybase.