Hi-

I have many areas where I perform Go To Related Record in file
"A" (find only related, and only for the current record) in another
file "B"

Then I want to do something, like delete the current B record, or
perform some other task in B.

In FM5/6 this was dead simple no brainer activity.

But in FM8 I am seeing that if I don't specify a layout in the B file
(it gets specified in the GTRR script step in A), then I can get
unpredictable results such as tons of B records found that are not
related, or even all B records found.

As you can imagine this plays havoc with my scripting.

Why does FM care what layout I am specifying in B?? It should just go
to B with the correct found set.

Does anyone know why this happens?

In article <1181330892.777664.55250 (AT) k79g2000hse (DOT) googlegroups.com>
PaulBruneau <paul (AT) ethicalpaul (DOT) com> wrote:

introduced with FM7. Because we can now have any number of layouts
displaying information from any number of tables, it stands to reason
that the destination layout must be specified.
I suppose GTRR could just arbitrarily go to any layout displaying
records from the table on the other side of the relationship, but that
could probably cause considerably more damage. The prudent thing being
to specify the layout, the folks at FileMaker made it a requirement so
that it wouldn't be inadvertantly forgotten.
Matt

--
I'm trying a new usenet client for Mac, Nemo OS X.
You can download it at http://www.malcom-mac.com/nemo

On Jun 8, 12:28 pm, Paul Bruneau <p... (AT) ethicalpaul (DOT) com> wrote:
On Jun 8, 12:28 pm, Paul Bruneau <p... (AT) ethicalpaul (DOT) com> wrote:
GTRR has multiple personality disorder. Seriously.

It was bad before, with different behaviour based on whether or not a
portal row was active, but now its just psychotic.

Too answer your question, 'Why does FM care what layout I am
specifying in B'?

B doesn't have 'A found set' anymore; it has a multitude.

It has a distinct 'found set' for each Table Occurrence (TO) in the
Relationship Graph (RG) for each window open on B. By specifying which
layout to use you indirectly determine which of those found sets is
updated.

If you specify a layout-A showing records from TO-A, on Table-A in
File-A and then look at another layout (layout-A2) which is defined on
TO-A2, which is also Table-A, you'll see that the two layouts on the
same table have independent found sets.

If you go into File-B, create a file reference to File-A, create a TO-
A3 on Table-A, create a layout-A3 on TO-A3 you'll find that it too
will have a separate found set from the 2 layouts in File-A.

GTRR now performs TWO distinct functions. First, as before when you
GTRR you specify a TO (previously this was just a child relationship);
now this defines the relationship 'path' to be used, and along with
the checkbox options for the GTRR script step defines the 'found set'
of records that will be returned.

Previously the 'found set' was returned in the *only* place it could
be: in the single found set of the file that hosted the other side of
the relationship (whether it was a self-join, or an external file). As
ALL layouts of that file shared the found set, layout choice was
irrelevant.

With FM7+ life isn't so simple. There are now potentially several
places that found set can be returned... in any TO on that file either
in the file calling GTRR, or in any TO on the file the table actually
resides in. Because each layout is based on a TO, selecting a
destination layout indirectly identifies which TOs found set gets
'replaced'.

**Note that all layouts within a single window that are defined on the
same TO share a found set.**

Finally, last but not least, a requirement you'll bump into as you get
deeper into FM7+ is to move a found set from one TO to another TO
defined on the same table. In previous versions of FM the found set
for a table was its found set, but now, with multiple 'found sets' for
a given table, and because different TO's occur in different places in
the RG (and relational expressions in scripts evaluate differently
depending on your local context - ie what TO the current layout refers
to) you'll find the need to move a found set from TO to TO in order to
leverage the RG context.

To do this, of course you use GTRR. Starting on layout-A, on TO-A, on
Table-A, and wanting to end up on layout-Aprime, on TO-Aprime, on
Table-A you GTRR to TO-A, with destination layout-Aprime, checking off
for all records in the found set.

Essentially a record is implicitly related to itself. So a GTRR that
doesn't 'go' anywhere and then deposits the result into another TOs
found set amounts to transferring the original found set.

It makes perverse sense, I guess.

I doubt I was clear, so feel free to ask for clarification where
needed.

-cheers,
Dave

Thanks guys for a nice couple of responses!

Yikes, I guess I should consider myself lucky that I've only had this
bite me a couple times.

Your answers prompt for me a second question though--lets say I do
specify a certain layout to be used for the result, and if I happen to
have several windows all viewing that layout, which window will FM use
to display my result?

On Jun 11, 7:47 am, Paul Bruneau <p... (AT) ethicalpaul (DOT) com> wrote:
It uses the active/current window. If the layout being viewed in that
window is based on a table occurance not related to the table you want
to go to nothing happens.

If you specify that it should be an external window, then it will use
the front-most one for that file and it will change to that layout.

Paul Bruneau wrote:
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Howard Schlossberg
FM Professional Solutions, Inc. Los Angeles

FileMaker 8 Certified Developer
Member, FileMaker Business Alliance