Jump to content

Related Related Portal fields


Phillip Prahl

This topic is 3094 days old. Please don't post here. Open a new topic instead.

Recommended Posts

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!

 

Link to comment
Share on other sites

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
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

This topic is 3094 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

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