Troubleshooting

Portal Rows Not Displaying

I know I have a valid relationship established, but some (or all) of my portal rows aren't showing. What could be some of the issues?

You can opt to display only a specific set of rows via Portal Setup format options, but it is possible that you'd have a case of related records in your data that would never show up for a user . If you turn off vertical scroll bars and set a portal to show rows 4 “8, rows 1 “3 and 9+ won't display.

This applies to creating rows as well. If you've allowed the creation of related records and a portal's bottom-most row is intended to allow such, your users cannot access that feature if the row falls outside your range of visibly formatted rows. As in the example of only showing rows 4 “8, there would have to be already at least three related records in the database before the "editable row" would appear for users.

Creating Related Rows for Non “ Equijoin Relationships

How do I create records via relationships that aren't equijoins ? The option is grayed out.

When you allow creation of related records in a relationship, you may have noticed this works only for the equijoin ("=") operator. In cases where your primary relationship is driven by a different operator, we recommend still establishing an equijoin relationship with different table occurrences to create new records. If you're still not happy doing so (perhaps over concerns of cluttering your relationships graph), the only other alternative is to create a script that takes a parameter ”the primary key of your parent table's current record ”navigate to a layout attached to your child table occurrence, and use the create new record/request script step in combination with a manual Set Field [childTable::keyF_ParentID; Get (ScriptParameter)] for the match key.

Incomplete Highlighting Rectangle

My row highlight is showing in its container field, but it doesn't fill the entire portal row well. Where should I first look to address this?

If you place an image in a container field, and then have a calculation display the contents of that container field in a portal row, even when Maintain Original Proportions is enabled, your rectangle may show whitespace on either side. This is further complicated if you are trying to put something more complex than just a colored rectangle in the highlight field. FileMaker's resizing of images can be unpredictable at times.

The best way around this in many cases is to simply make the image larger than you need it to be and set the graphic format to Crop.

Multi-user Selected Data

I have used a straight field ”not a global ”for storing which related record I want selected in a selection portal and related fields. In multi-user environments, this will break if two users are working with the same record at once. How do I work around that problem, while still not using globals that might display the wrong related data for a given record?

In cases where the field tracking a portal row selection is a standard field, as opposed to a global field, you will run into problems in multi-user environments. Two users might be viewing the same record at the same time and make two different row selections on a portal. Only one state would be valid (the latter of the two), but no event or screen refresh would occur for the first user.

There are two ways to deal with this. To employ the first, make certain users never end up working with the same record by either scripting a check-in/ check-out approach or possibly building a one-record-only user interface for each user. This first approach is quite scripting and development intensive .

The second approach makes use again of multi-keys. To track what portal row is selected, keep track of your account name in a global field and populate a multi-key that concatenates accountName and rowID into the selectionID field. You need to use the substitute function to parse in-and-out as multiple users work with the portal, but this is multi-user “safe so long as they don't run into actual record locking problems.