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.

Related Related Portal fields

Featured Replies

Newbie question here - so please be kind :)

In a record belonging to the table "company"I  have a portal that shows related records from the table "tasks".

The table "tasks" has a field called "subject" and this is being shown in the portal correctly.

The table "tasks" also has a field called "id_user", but rather that just showing this (which is an integer), I would like to show the first name of the user. This information however is not stored in tasks, but in a table called "users".

I have found two solutions (I like the latter better), but was curious to what is the common approach.

Solution 1: Create a relationship between the table "tasks" and the table "users". Then simply add a merge field with "users::user_name".

Solution 2: Create a value list (relating user_id and user_name) and place a pop-up menu in the portal that uses this.

Solution 3: ... The one that the newbie didn't even know was possible?

In advance, thank you so much for any and all help!

 

The table "tasks" also has a field called "id_user" … Solution 1: Create a relationship between the table "tasks" and the table "users".

If you didn't already create a relationship between Tasks and Users, why do you have a field id_user in tasks?

Anyway, both solution 1 and 2 are OK, though you will want to create that relationship from #1:

Task::id_user >-- User::id

because this gives you access to all the data in the related user's record from within the context of a Task record.

Solution 2 is a fast and uncomplicated way to facilitate data entry: format the id_user field in the portal as popup with that value list – and remember that in the VL definition you can opt to only show values from the second field, i.e. the name.

Then simply add a merge field with "users::user_name".

That, or add the field User::name itself.

Edited by eos

  • Author

Thank you for the quick respone.

The reason for the id_user is precisely so that I can make a relationship at a later point. My hesitation to use it was that I end up with a rather large relationship graph (well large for a newbie). Basically I feel that I end up with a new relationship graph per layout. Its not quite that 'bad' but let me explain.

(This topic may need to be moved to relationships now...)

So, say I have a layout that shows records from the table "companies". This layout has a portal that shows both "employments" and "checkins" in separate portals and these show information from users. To accommodate this I have made relationships that looks as shown in (a). 

Now I would like to also have the "checkins" portal to show info about "contacts", but fmp will not let me do this unless I create a new dependency instance. Which yields (b).

So far so good. However, I have another layout which is identical to the above, except it shows records from "contacts". So, as far as I can tell, I have to build a whole new dependency graph which I have shown in (c).

It this a proper filemaker workflow?

Is it common to have to rebuild very similar dependency graphs as you create new layouts (that show records from the tables)?

Thanks again for all the help.

 

 

 

 

 

 

 

a.png

b.png

c.png

  • Author

I got a bit smarter after I ran into the anchor buoy concept :)

 

Well, what you did there essentially is the Anchor/Buoy model; but relationships can work bi-directional, so given a simplified data model of

People --< Employment >-- Company

you could simply base your working layout for each of these entities on the one existing TO for each.

In the A/B version you would have something like

PEOPLE__People --< people__Employment >-- people__Company

COMPANY__Company --< company__Employment>-- company__People

base your respective working layout on the ALLCAPS TO, and from there only work within the respective TOG.

  • Author

Makes sense -Thanks again!

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.