Jump to content

Somebody tell me it is not a FM7 BUG !


carlocas
 Share

This topic is 6716 days old. Please don't post here. Open a new topic instead.

Recommended Posts

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 ?

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

This topic is 6716 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.