I have a parent table called Supplier and child table called
Supplier Contacts. Each Supplier can have multiple Supplier
Contacts. I would like to list multiple Supplier Contacts on the Supplier
record (ideally based on some conditional criteria related to Supplier Contact
fields).
Is there a way to do this? I have pulled child record data into parent
records before, but only info from one child. This would have one or more
different child record data (maybe concatenated) displayed on the parent record.
Thanks,
Tony
-
100 Points
Posted 4 months ago
-
546 Points
If the children records are appropriately linked to a parent record, it should automatically be able to pull it up through an embedded report, which you can have it displayed via the form under a parent record.
-
934 Points
Do you have an example you can think of? I think I understand what you are asking, but it's hard to follow.
I would like to list multiple Supplier Contacts on the Supplier recordParent/child relationships do this automatically with embedded reports
(ideally based on some conditional criteria related to Supplier Contact fields)Need specifics or example, I'm not sure what you mean on this part.
QuickBaseCoach App Dev./Training, Champion
-
60,108 Points
Here is an answer to a similar question.
In this case the Parent is Jobs and the Child is Operators and the goal is to float the Operators' names all up to the parent record into one concatenated field.
The way to do this is with as many "reverse relationships" as you guess will be enough to cover off 99% if the situation.
So, let talk about Operators. One Job has many Operators. Make a summary field on that relationship of the Minimum of the Record ID# of Operators. Call it [Record ID# of Operator 1].
Then do a lookup of that down to the child Operator table as we will need it later.
Then do a new Relationship where one Operator has many jobs. For the reference field (the field on the right side), use that new Summary field called [Record ID of Operator 1]. Get rid of the extra fields that get created on the left side of the relationship (Add Operator and that report link field). Do a lookup from the Operator down to Jobs and bring in the Operator Name and call it Operator 1.
Wonderful, the Job now knows the first Operator.
Now, make a duplicate of that summary field, but in the duplicate add the extra condition that the [record ID#] is greater than the [Record ID# of Operator 1]. Call it [Record ID# of Operator 2]. Do a lookup of that field back down to the Child Operator table as we will need it later.
Now, in making that duplicate, conveniently, you will find that it duplicated the reverse relationship so now do a lookup in that relationship of the operator name called it [Operator 2]. Wonderful again, we now have Operator #2's name on the Job Record.
Then make another duplicate of that summary field and just keep going, each time changing the filter so that the record ID# is greater than the previously highest record ID of Operator.
In the end say you collect the names of the first 4 operators on a job, so then just string them together in a formula like
List ("\n",
[Operator 1],
[Operator 2],
[Operator 3],
[Operator 4])
and put that concatenated field list on your report.
In this case the Parent is Jobs and the Child is Operators and the goal is to float the Operators' names all up to the parent record into one concatenated field.
The way to do this is with as many "reverse relationships" as you guess will be enough to cover off 99% if the situation.
So, let talk about Operators. One Job has many Operators. Make a summary field on that relationship of the Minimum of the Record ID# of Operators. Call it [Record ID# of Operator 1].
Then do a lookup of that down to the child Operator table as we will need it later.
Then do a new Relationship where one Operator has many jobs. For the reference field (the field on the right side), use that new Summary field called [Record ID of Operator 1]. Get rid of the extra fields that get created on the left side of the relationship (Add Operator and that report link field). Do a lookup from the Operator down to Jobs and bring in the Operator Name and call it Operator 1.
Wonderful, the Job now knows the first Operator.
Now, make a duplicate of that summary field, but in the duplicate add the extra condition that the [record ID#] is greater than the [Record ID# of Operator 1]. Call it [Record ID# of Operator 2]. Do a lookup of that field back down to the Child Operator table as we will need it later.
Now, in making that duplicate, conveniently, you will find that it duplicated the reverse relationship so now do a lookup in that relationship of the operator name called it [Operator 2]. Wonderful again, we now have Operator #2's name on the Job Record.
Then make another duplicate of that summary field and just keep going, each time changing the filter so that the record ID# is greater than the previously highest record ID of Operator.
In the end say you collect the names of the first 4 operators on a job, so then just string them together in a formula like
List ("\n",
[Operator 1],
[Operator 2],
[Operator 3],
[Operator 4])
and put that concatenated field list on your report.
-
100 Points
So I think Mark's suggestion will work. I was hoping there might be a more efficient way, but likely not.
Example for Everett.
We interact with 7 different reps at Energy Supplier A.
Rep 1 handles electricity in MA
Rep 2 handles electricity in NY
Rep 3 handles natural gas in MA
Rep 4 handles electricity and natural gas in MA
Rep 5 handles fuel oil in MA
Without getting into some real confusing aspects of our process, I want to summarize on the supplier record the reps that handle various combinations of territory and commodity. So conceptually Marks approach works, although I need to think about the combinations to determine if it is practical.
Thank you.
Example for Everett.
We interact with 7 different reps at Energy Supplier A.
Rep 1 handles electricity in MA
Rep 2 handles electricity in NY
Rep 3 handles natural gas in MA
Rep 4 handles electricity and natural gas in MA
Rep 5 handles fuel oil in MA
Without getting into some real confusing aspects of our process, I want to summarize on the supplier record the reps that handle various combinations of territory and commodity. So conceptually Marks approach works, although I need to think about the combinations to determine if it is practical.
Thank you.
Alex - Direct Line Teleresponse
-
2,294 Points
It's only a problem if your process requires information from more than one field be concatenated into one field at the parent record.
If you're concatenating multiple values in the SAME field, there's a new native summary field type that will do that.
If you only need visibility to all child records, an embedded report (on [Related Supplier]) will do that easily.
If you're concatenating multiple values in the SAME field, there's a new native summary field type that will do that.
If you only need visibility to all child records, an embedded report (on [Related Supplier]) will do that easily.
Related Categories
-
Relationships
- 2578 Conversations
- 40 Followers
-
Tables & fields
- 7118 Conversations
- 163 Followers