weird issue with committing records

January 31, 201312 yr

Newbies

Attached is file I am having trouble with. Any help would be appreciated. The problem is with two tables: Projects and Samples in a database sitting on a remote filemaker server. I have a Layout "Projects" with records from table "Projects". Also that layout is a portal displaying related records from table Samples. People create related records in Samples by entering values in four fields displayed in the portal. They can press a button to go to a Layout "Samples" to show records from Table "Samples" and enter additional data in other fields.

It's a routine setup. My problem? I have a related field (called ProjectName) from Projects displayed on Layout "Samples" that doesn't show any values even though the record was created using the portal in the Projects Layout. The two fields (both named _k_ProjectID) that connect the two tables have the same identical values, thus fulfilling the relationship. Yet Layout Samples doesn't show any related info from table Projects.

BUT if I close the file and then reopen it, all the related info show up. Very strange.

Any ideas? Am I missing something obvious? I tried committing records and that didn't help. When I am going between screens, FM is naturally refreshing the window so that shouldn't be an issue. It seems like a commit records issue but when I leave a portal row, that row should be committed, right?

So if you want to reproduce my issue:

1. Open file and enter Field "Brought By" and enter any text. Tab to go to the next field.

2. Press the little black arrow at the end of row to go to the Samples Layout and see that related info.

3. Notice that ProjectName is blank -- ProjectName.

4. Close the file. Reopen it. Go to Samples screen. Show all if you have to. Notice ProjectName now appears.

Thanks in advance.

stumped,
john

Complex Protein ID.fmp12.zip

February 2, 201312 yr

when you navigate away to samples your record is not committed yet (the get(recordopenstate) = 2). So instead of attaching the go to related directly to a button, create a script that commits first before going to the related record. That has the added benefit of being able to trap for and handle errors that may happen on the commit.

The idea is to avoid "implicit coding" as in relying on FM to do the commit for your by virtue of going to another layout, and use "explicit coding" where you explicitly take control over what happens when.