The unlock record feature is designed as an override for situations where a clubber is locked (in either the primary or a secondary db), but the person with the database having the locked record wants 'ownership' of the record.
So, for a secondary db, using the unlock allows the user of the secondary db to take 'ownership' of the record, make changes and then the record will be checked in as if the record had been checked out.
For a primary db, using the unlock allows the user of the primary db to take 'ownership' of a checked-out record, make changes and then the record will be treated as if the record had not been checked out (the check-in process will ignore it in the secondary db that originally had the unlocked record).
Here is an example of when it might be used: John attends as a Spark clubber but then quits coming. His record gets archived. Later, John comes to T&T with a friend and says "I used to come a long time ago". The T&T secretary, who has only the T&T records checked out, finds John's record but it is locked. At this point, the T&T secretary can take 'ownership' of the record by using the unlock feature thus allowing complete access to John's record. Any changes made in the secondary db will then be checked back into the primary db following all of the usual check-in processes.
It is not intended to be used to make changes to a locked record that is known to be in active use by the 'owner' of the record. The person who has 'ownership' of the record should be the one making those changes.
Here is an example of what not to use it for: Brian is an active T&T clubber and the T&T secretary has the T&T records checked out. The Sparks secretary has the primary database. Brian's mom comes with her daughter who is a Sparks clubber to the Sparks secretary and says "Can you register Brian along with Beth?" The Sparks secretary sees that Brian's record is locked. If the Sparks secretary unlocks Brian's record to mark his registration information, she becomes the 'owner' of that record. Meanwhile, the T&T secretary is marking attendance and handbook sections in the secondary db for Brian because she thinks she has ownership of Brian's record (which she should). When the secondary T&T database is checked back in, the primary db will see that it has ownership of Brian's record and will not check in his record from the secondary db, thus losing all of the T&T secretary's work on his record.
The best way to make a decision about using the unlock is to consider the question "should I have ownership of this record or does the person who currently has the unlocked record need to keep ownership?"
As to synchronization, I assume that you mean you would like to make some changes in the primary db to a member's record and also allow changes in the secondary db; but then when the record is checked in 'sync' the two records up. The problem with this is we don't have any way of knowing which changes you really want to keep if there are conflicts in the records. That is why there is a lock. This feature simply acknowledges that there are some situations involving checked out databases where ownership of the record needs to be switched without having to check-in the secondary database, make a change and then check it out again.
