Somebody tell me it is not a FM7 BUG !

[carlocas]

I want to display one adress at a time of a customer record

I've created a relationship that links a "location" field located in the customer table to a "location" field inside the "address" table.

A script dynamically changes the address displayed by simply changing the content of a "location" field inside the customer table...

HERE IS THE UGLY PART : The related address is displayed only when at the end of the script I go from Preview mode to Browse mode !

Tell me I'm doing something wrong... It worked perfectly in v6...

Version: Server v7

Platform: Mac OS X Panther

[Vaughan]

You need to put a "Commit Record/Request" step at the need of the script.

"It worked perfectly in v6"

FMP 7 is a new program. Not just a new version.

[Steven H. Blackwell]

Vaughan gives you good advice. Set Field per se no longer commits a record. That also means of course that the record is still open and locked. When your eceive a message to the effect that the record can not be edited because it's already being edited in another windows, you'll have found an example of this.

Stay tuned for additional information [in very great depth] on record locking and commits in FIleMaker Pro 7:

http://www.filemaker.com/upgrade/techbriefs.html

Steven

[carlocas]

Sorry to tell you that I had tried the "commit record" script step... and that did NOT work.

Even the "Filemaker Business Tracker" application uses the "Preview Mode" then "Browse Mode" trick to switch between the Addresses of a contact... scary.... So in other words is it a bug/serious flaw ?

[carlocas]

OK... I've checked the "Show field frames when record is active" option in the Layout setup, and now when you commit the record it updates correctly...

Why ? How is that related to my problem ?

[bruceR]

You can also use Freeze window before your set field operation.

[carlocas]

Thank you... for this tip, but is this a normal behavior ?

[Vaughan]

There are a couple of issues here. The refreshing of portals has always been tricky, and the ease to which it is done depends on the relationship and the fields used as keys: unstored calculations especially require an extra bump because the calculation has to be re-evaluated for the relationship to be re-evaluated before the portal can be re-evaluated.

Portal refresh difficulties have also bee traced to having data-type mismatches between keys on either side of the relationship (typically number on one side and text on the other) and having invalid fields in the relationship definition's sort order (specifying to sort by a related field then deleting it from the related database).