Record Level Access Inconsistency

July 4, 200619 yr

I'm finding some interesting behaviour with FMP 8.0v3 on Windows XP that was recently converted from FMP 5.5. It also occurs with newly created FMP 8 databases: see the attached demo file.

I have record level access set up through an unstored calculated number field called RecordAccess. RecordAccess is defined as gRecordID = RecordID where RecordID is an auto-entered serial number (in a text field). Records are unlocked when the global field contains the unique ID value (simple auto-entered serial numbers).

All of this works very well in FMP 5.5. However in FMP 8.0v3 it can be unreliable. It appears that the RLA doesn't always update. The result is that about 1% of the time the records remain locked (or unlocked) even thought the global field has the primary key value. When this happens, committing the record or refreshing the Window (even with the joins thoroughly flushed) provides no relief.

Even more interesting, if the script that unlocks the record is called as a sub-script from another script the unlocking process fails completely! The only way to force an update is to change records: the Refresh Window script step does not seem to be enough.

I'm working around the problem by performing two "Show Omitted Only" script steps one after the other, but I hate hacks like this... I'm dying to know what needs to be done to make it work elegantly.

Your assistance would be appreciated.

RLA_Test_2.zip

Edited July 5, 200619 yr by Guest

July 5, 200619 yr

Author

I just tested the file in Mac OS X – it shows the same behaviour.

FMP 8.0v3 Advanced, OSX 10.3.9, eMac G4.

July 5, 200619 yr

The only way to force an update is to change records: the Refresh Window script step does not seem to be enough ... I'm dying to know what needs to be done to make it work elegantly.

FWIW (and in case others are having this problem), it appears that including the steps:

Go to Field [Table::FieldName]

Commit Records/Requests [skip...; No dialog]

- on the tail end of the calling script, provides a more elegant work-around.

Why this problem occurs when the script is called by another scriptg, but not when it is called directly is unclear. Let's hope the behavior is corrected in a future rev/release.