Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.databases.filemaker > #2563 > unrolled thread

Linked Record in Layout

Back to article view | Back to comp.databases.filemaker

Contents

  Linked Record in Layout csampson@inetworld.net (Charles H. Sampson) - 2016-02-07 19:34 -0800
    Re: Linked Record in Layout Helpful Harry <HelpfulHarry@BusyWorking.com> - 2016-02-08 16:52 +1300
      Re: Linked Record in Layout Helpful Harry <HelpfulHarry@BusyWorking.com> - 2016-02-08 16:58 +1300
      Re: Linked Record in Layout Howard Schlossberg <howard@nospam.fmprosolutions.com> - 2016-02-07 20:09 -0800
    Re: Linked Record in Layout clkaufmann@gmx.ch (Christoph Kaufmann) - 2016-02-08 20:32 +0100

#2563 — Linked Record in Layout

When I was learning the FileMaker way of doing things, I created a
number of layouts in which a "regular" field showed data from a related
table. That is, without benefit of a portal.

By and large, this has worked as I wanted it to. I'm currently having
trouble with one such layout. Before I describe that problem
specifically, I'd like to get information about this approach in
general. When is this way of doing things acceptable and when should
portals be used? I realize that the answers to these questions might be
"never" and "always".

Charlie
-- 
Nobody in this country got rich on his own.  You built a factory--good.
But you moved your goods on roads we all paid for.  You hired workers we
all paid to educate. So keep a big hunk of the money from your factory.
But take a hunk and pay it forward.  Elizabeth Warren (paraphrased)

[toc] | [next] | [standalone]

#2564

In article <1mi8zn4.1i2u3kg1qpwdk2N%csampson@inetworld.net>, Charles H.
Sampson <csampson@inetworld.net> wrote:
> 
> When I was learning the FileMaker way of doing things, I created a
> number of layouts in which a "regular" field showed data from a related
> table. That is, without benefit of a portal.
> 
> By and large, this has worked as I wanted it to. I'm currently having
> trouble with one such layout. Before I describe that problem
> specifically, I'd like to get information about this approach in
> general. When is this way of doing things acceptable and when should
> portals be used? I realize that the answers to these questions might be
> "never" and "always".

As always, it will depend on what you are trying to achieve and why.

A Portal is usually used to show data from multiple related records on
the layout for the Parent record. It's usually not a good idea to use
Portals on print / Preview layouts, but instead print from a layout for
the Child records (using a backwards Relationship link to obtain Parent
record data if needed).

Putting a single related field onto a Parent record layout will only
ever display the data for the FIRST related record (which record is
"first" will depend on the sort order for the Relationship).

You can of course use also use a single calculated or Summary fields in
the Parent record table to do things like Sum or Average all related
Child record data via the Relationship link.
e.g.    RelatedAverage = Average(Relationship::ChildNumberField)


Helpful Harry  :o)

[toc] | [prev] | [next] | [standalone]

#2565

In article <080220161652451040%HelpfulHarry@BusyWorking.com>, Helpful
Harry <HelpfulHarry@BusyWorking.com> wrote:

> In article <1mi8zn4.1i2u3kg1qpwdk2N%csampson@inetworld.net>, Charles H.
> Sampson <csampson@inetworld.net> wrote:
> > 
> > When I was learning the FileMaker way of doing things, I created a
> > number of layouts in which a "regular" field showed data from a related
> > table. That is, without benefit of a portal.
> > 
> > By and large, this has worked as I wanted it to. I'm currently having
> > trouble with one such layout. Before I describe that problem
> > specifically, I'd like to get information about this approach in
> > general. When is this way of doing things acceptable and when should
> > portals be used? I realize that the answers to these questions might be
> > "never" and "always".
> 
> As always, it will depend on what you are trying to achieve and why.
> 
> A Portal is usually used to show data from multiple related records on
> the layout for the Parent record. It's usually not a good idea to use
> Portals on print / Preview layouts, but instead print from a layout for
> the Child records (using a backwards Relationship link to obtain Parent
> record data if needed).
> 
> Putting a single related field onto a Parent record layout will only
> ever display the data for the FIRST related record (which record is
> "first" will depend on the sort order for the Relationship).
> 
> You can of course use also use a single calculated or Summary fields in
> the Parent record table to do things like Sum or Average all related
> Child record data via the Relationship link.
> e.g.    RelatedAverage = Average(Relationship::ChildNumberField)

Sorry, I meant to say that a calculated field in the Parent record that
does not use of the aggregation functions (i.e. Sum, Average, etc.)
will also return data from the first related record. 

For example, a Calclation field in the Parent record that is defined as:

     ChildAdd = Relationship::FieldA + Relationship::FieldB

will only calculate the result using the first related record's FieldA
and FieldB data.

If you want it to be a total of all the related records' FieldA and
FieldB data, then it needs to be something like:
     ChildAdd = Sum(Relationship::FieldA) + Sum(Relationship::FieldB)


Helpful Harry  :o)

[toc] | [prev] | [next] | [standalone]

#2566

On 2/7/2016 7:52 PM, Helpful Harry wrote:
> In article <1mi8zn4.1i2u3kg1qpwdk2N%csampson@inetworld.net>, Charles H.
> Sampson <csampson@inetworld.net> wrote:
>>
>> When I was learning the FileMaker way of doing things, I created a
>> number of layouts in which a "regular" field showed data from a related
>> table. That is, without benefit of a portal.
>>
>> By and large, this has worked as I wanted it to. I'm currently having
>> trouble with one such layout. Before I describe that problem
>> specifically, I'd like to get information about this approach in
>> general. When is this way of doing things acceptable and when should
>> portals be used? I realize that the answers to these questions might be
>> "never" and "always".
>
> As always, it will depend on what you are trying to achieve and why.
>
> A Portal is usually used to show data from multiple related records on
> the layout for the Parent record.
(snip)
>
> Putting a single related field onto a Parent record layout will only
> ever display the data for the FIRST related record (which record is
> "first" will depend on the sort order for the Relationship).
(snip)


In addition to what Harry says, the behavior in find mode can seem 
quirky when not using the portal.  The find behavior either way is 
exactly the same, but since the non-portal method only shows the first 
record, you can do a find that finds the parent records based on unseen 
but related records.  Because the find is based on all related re4cords 
but the non-portal display is only on the first record, it can "appear" 
as though FileMaker has found the wrong records.  But it's not the find 
that's wrong, it is the display that is incomplete (by your design).

Howard

[toc] | [prev] | [next] | [standalone]

#2567

Charles H. Sampson <csampson@inetworld.net> wrote:

> a
> number of layouts in which a "regular" field showed data from a related
> table. That is, without benefit of a portal.
> 
> When is this way of doing things acceptable and when should
> portals be used? I realize that the answers to these questions might be
> "never" and "always".

I use that in a child record of a 1:n relation. The field in question
will show the value of the only related record there is.

For the same reasons, a portal is more appropriate if there might be
more than one related record.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.databases.filemaker

csiph-web