Related Related Portal fields

[Phillip Prahl]

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!

 

[eos]

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 September 14, 2015 by eos

[Phillip Prahl]

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.

 

 

 

 

 

 

 

[Phillip Prahl]

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

 

[eos]

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.

[Phillip Prahl]

Makes sense -Thanks again!