Dynamic Portal Sorting

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 scrollbars and set a portal to show rows 48, rows 13 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 bottommost 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 showing only rows 48, there would have to already be 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 that this works only for the equijoin (=) operator. In cases in which 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 parameterthe primary key of your parent table's current recordnavigate 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::_kf_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 problem?

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 situation in many cases is to simply make the image larger than you need it to be and set the graphic format to Crop.

Multiuser Selected Data

I have used a regular fieldnot a global fieldfor storing the ID of the related record I want selected in a selection portal and related fields. In multiuser 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 in which the field tracking a portal row selection is a standard field, as opposed to a global field, you will run into problems in multiuser 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 problem. To employ the first, make certain that 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 multiuser-safe as long as they don't run into actual record-locking problems.