Relookup sometimes fails to modify current record (2 Comments)

Issue report by Dillik

Product

FileMaker Pro

Version

13.0v3

Operating system version

OS X 10.7.5

Description of the issue

The Relookup script step can fail to update the current record in a particular scenario.

Steps to reproduce the problem

1) Define a lookup field (LF) which uses a relationship based on some local key field (KF).
2) Create several records which have values in LF which differ from the value they will look up when a Relookup is performed.
3) Place a button on the layout which performs a relookup using KF. (The intent is to force LF to update across the found set when the KF-based relookup is performed.)
4) In one of the records, begin editing any field other than KF (it may be LF, but it doesn't have to be). Leave the cursor here.
5) Press the button to perform the relookup.

Expected result

LF should have been updated across all records in the found set (including the current record, despite the field's unsaved state in the current record).

Actual result

The value of LF in the current record remains unchanged (without an error code being generated), while LF has been updated in all other found records.

If the field being edited was KF (this is what Relookup was probably written to expect, setting aside the Relookup step being able to specify a different field), the problem doesn't occur: an unsaved KF value doesn't interfere with the current record being modified (and the unsaved value is also used in the relookup, which is nice).

We can even avoid the problem by entering and modifying KF after modifying LF: simply exiting LF to render it "saved" (record's open state aside) means there is no field (other than KF, which doesn't count) in an unsaved state, and the relookup proceeds as expected.

Workaround

Before performing the Relookup step (if anyone even still uses relookups), it would be helpful for a script to first go to KF to make sure there is no unsaved field (other than KF) when the relookup runs. Or you could just commit first, if you prefer the blunt approach.