
Data entry works the same way it does in other areas of FileMaker: Simply click into a field and enter whatever data is appropriate.Īt times, developers include buttons in portals. To browse through your related records, simply scroll up and down through the list.

They feel a bit like List views and act much the same way. Most portals have a scroll bar on the right. Developers determine the rules by which records appear in portals, and at times the records displayed can dynamically change or a portal might display other records in the same table you’re currently viewing.

As you will see in Chapter 3, for the case in which the same people are assigned to several projects, there is a slightly more complex database structure (it is referred to as a many-to-many relationship.) Understanding the Mechanics of a PortalĪ portal is simply a view into another table and includes rows of specific related records. This means that, just as you can display the people for a project, you can turn it around and display the project for a person if the database is so configured. For each parent record - each department - you’ll need to first identify the IDs of the related employees.Relationships are bidirectional. In the following example, we will be looking at departments and their related employees. You may also have some geeky fun in the process. The user gets the user interface they want, and you get to keep the relationship graph under control. Using functions in the presentation layer obviates the need for additional relationships and table occurrences.

If users have a strong preference for navigating with previous and next buttons, however, this function provides that feature without requiring significant development time. Nine times out of ten, users have no objection to navigating with scroll bars, which FileMaker handles just fine. Why would you choose this scripted approach over simply providing a scroll bar? As a rule of thumb, I generally employ native FileMaker functions and features over something I have to script and manage myself. Arrow icons or buttons provide the user with the ability to view sets of records without having to scroll. With a script trigger and a few global variables, you can implement this feature in any database where parent records display child records.

I know this is possible when the filtering occurs on the Relationship Graph but I can’t figure out how to do it when the filtering occurs on the presentation layer in FileMaker 11.Ībsolutely. Buttons will take the user to the first, previous, next, and last set of records in the portal. Is it possible to create a portal paging system with filtered portals in FileMaker 11? I am interested in showing a portal without the scroll bar.
