FMP 10 Adv: When using GTRR in a script, you want to be sure in what
context/layout you land. Which test works best for you?

- use the count function to check whethe related records exist
- use a get function after the GTRR to check what the underlying table
is
- get last error after GTRR
- others?

I used the first method so far, but it's no use if I have to go to the
related recods of all the records in my found set.

I tried the third option - get last error - but I get error 101 (missing
record) even though lots of records were found and GTRR worked as
expected. I assume I get error 101 when there's at least one record in
the found set with no related records (which is irrelevant).

Meaning I have check for context and found records after the GTRR. I
don't like it because it means I have to hard code the name of the TO in
the test.
--
http://clk.ch

On Jul 3, 1:44*am, c... (AT) tele2 (DOT) ch (Christoph Kaufmann) wrote:
It's unclear what you're trying to accomplish, but two things come to
mind:

1) Error 401 is a better test than 101. You get 101 when matching the
found set and the record that's currently active has no related
record. 401 pops up when there's no related records at all.
2) Are you using this db locally or over a network? I find GTRR
matching the found set to be extremely slow over a network. I've
tested it and found it faster to loops through the found set, setting
a global field to the related keys and GTRR on a new relationship
based on that global field, matching the current record only.

DJ

On 2011-07-02 22:44:49 -0700, clk (AT) tele2 (DOT) ch (Christoph Kaufmann) said:

If what you're trying to test is whether related records exist, use a

If [not isempty(Relation::KeyField)]
GTRR
Else
Exit script
End If

routine. This is MUCH faster than Count, as Count actually has to
calculate the count of related records. If there are a lot of them,
it's slow. The Not isempty() simply calculates if there is one related
record and is much faster.

And for those who wonder at the reason to test first before the GTRR,
in FM 9 & 10, if you GTRR to an empty set, you actually don't go
anywhere, you remain on the current context. Any operations you script
such as Delete All Records, will take place in the wrong context. Yipe!

Always wise to test first.
--
Lynn Allen
--
www.semiotics.com
Member FBA
FM 10 Certified Developer

On 3/07/11 3:14 PM, Christoph Kaufmann wrote:

conditionally test IsValid( rel) BEFORE going anywhere



If [ IsValid( Diagnoses_children::diagnosis_id) ]
Go to Related Record
[ From table: “Diagnoses_children”; Using layout: <Current Layout> ]
[ Show only related records ]
Else
Show Custom Dialog [ Message: "No children"; Buttons: “OK” ]

End If



As for network speed, I would suspect that FM is downloading ALL records
that match the GTRR criteria to the CLIENT, and performing the find AND
sort, on the CLIENT. Could be wrong on this.

This was/(is) the case however with External Data Sources. I
encountered something similar on a very slow multi-criteria filtered
portal ( FM table to FM table) just last Friday, that appeared to be
downloading the entire (small c. 68,000) related record set) to
establish the portal set and then sort.

On Jul 3, 1:31*pm, David Jondreau <da... (AT) wingforward (DOT) net> wrote:
That should be "setting a global field to the *local* keys". Setting
to the related would be slow.

DJ

David Jondreau <david (AT) wingforward (DOT) net> wrote:

GTRR for all records of my present found set. Find out whether there are
related records at all. The found set may be 4'000 records, of which
1'500 have child records.

Great. I'll test for 401.

Good to know when speed issues come up. The db is local, though.
--
http://clk.ch

Lynn Allen <lynn (AT) NOT-semiotics (DOT) com> wrote:

I used that in my early days, then I read somewhere (in this group?)
isempty was not designed for this purpose and count was the proper way
:-)

--
http://clk.ch