The second approach makes use again of multi-keys. This first approach is quite scripting and development intensive. 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.
There are two ways to deal with this problem. Only one state would be valid (the latter of the two), but no event or screen refresh would occur for the first user. Two users might be viewing the same record at the same time and make two different row selections on a portal. 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. How do I work around that problem, while still not using globals that might display the wrong related data for a given record? In multiuser environments, this will break if two users are working with the same record at once. 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. 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. FileMaker's resizing of images can be unpredictable at times.
This is further complicated if you are trying to put something more complex than just a colored rectangle in the highlight field. 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. Where should I first look to address this problem? My row highlight is showing in its container field, but it doesn't fill the entire portal row well.
DYNAMIC PORTAL SORTING HOSTED FILES FILEMAKER PRO MANUAL
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 for the match key. 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. When you allow creation of related records in a relationship, you may have noticed that this works only for the equijoin (=) operator. How do I create records via relationships that aren't equijoins? The option is grayed out. 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.Ĭreating Related Rows for Non-Equijoin Relationships 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. If you turn off vertical scrollbars and set a portal to show rows 48, rows 13 and 9+ won't display. 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. I know I have a valid relationship established, but some (or all) of my portal rows aren't showing.
0 kommentar(er)
