Jump to content
View in the app

A better way to browse. Learn more.

FMForums.com

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Buggy 7 Portal Behavior

Featured Replies

Hi all:

I'm just working on a project in FMP7, and find that a couple of my portals are displaying very strange behavior indeed. Every now and then I'll reopen the project and find that the fields in a portal are no longer defined correctly. The layout is right, but the actual field definitions have changed. Granted, I've been fiddling with some relationship definitions, but the changes only manifest themselves when I close and then reopen the file. I have yet to try to replicate this behavior on purpose due to lack of time, but wondered if anyone had seen this sort of thing?

-Stanley

  • 3 weeks later...

I discovered some weird portal behaviour in 7 as well. After working with FileMaker technical support, we concluded that it was a bug. In my case, I had created a calendar file and set up the relationships as follows:

User -> Time Blocks -> Appointments

When the user logs in, a set of Time Blocks is created for him to populate a weekly schedule view. The Time Blocks table serves as a join between the user and his/her appointments. Each of the 28 Time Block records (1/2 hour blocks between 9 am and 11pm) contained date fields for Monday through Saturday. The calendar has six portals (Monday - Saturday). Each relationship is defined as Users::UserID = TimeBlocks::UserID *AND* Users::Monday = TimeBlocks::Monday, etc. This slotted each of the same 28 records into the six portals. Each of the six TimeBlocks portals is related to the Appointments file in the following way: TimeBlocks::UserID = Appointments::UserID *AND* TimeBlocks::Monday = Appointments::Date *AND* TimeBlocks::TimeBlockStart = Appointments::TimeStart, etc. This allows the proper appointment to show up in the right time block on the right day.

When the user changed the week view on his/her calendar (the User table contained globals for Monday through Saturday that were automatically populated with the current week's dates upon login), the Time Block dates were set to update automatically (calculated date fields based on the value of the globals in the Users table). But they didn't.

At first I thought I'd done something wrong, but everything checked out fine. The weird part was, if I opened the Define Database window and opened one of my calculation fields in the Time Blocks table, clicked OK and closed the Define Database window, everything updated. Strange indeed. Even stranger, if i viewed the Time Blocks records, they WERE calculating correctly. The portal would not recognize the change in date until I opened the Define Database window and viewed a calculation.

I figured out a sell sophisticated work-around using a script to update the Time Blocks, but there's definitely some funkiness with portals in 7, especially if you're using calculated fields.

-Rob

--

Rob Wyatt

[email protected]

Weird things happen in relationships if the defined sort order contains a field that has been deleted.

Create an account or sign in to comment

Important Information

By using this site, you agree to our Terms of Use.

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.