I recently got excellent advice in this Forum on how to get around the fact that Go To Related Records (GTRR) can't be used when you're trying to navigate from one layout to another but the layouts are based on calculations rather than being concrete references to something specific. (As I generalize my scripts, being able to navigate using calculations and variables becomes essential.)

The solution to my problem was to rely on Find rather than on GTRR.

However, I'm running into one persistent difficulty. Most of my layouts don't include a field for the serial number of the record. That is because my users shouldn't have to think in terms of serial numbers. Typically, I have only one representation of my table with an ID field containing the serial number. I'm sure this is common practice. But I need that serial number in my layouts to be able to find records when I try to navigate between TOs. With GTRR, that field wasn't necessary.

How do experienced FM developers deal with this issue? The only solution I can think of is to place an invisible field somewhere in the layout containing the serial ID. But this seems rather inelegant, not to mention untransparent to the developer, who might find it difficult later on to track these invisible, unlabelled fields. And it is especially tricky when you have a portal with no real room for an extra field.

Is there a better way to go about this? Thanks in advance to anyone with the necessary experience or insight.

I need that serial number in my layouts to be able to find records

Why?

BTW, this seems to be a follow up on:

http://fmforums.com/forum/showtopic.php?tid/215729/

Let's say I'm at a record in Layout 1, which shows records in Table using TO Table 1. I want to navigate to the related record in Layout 2, also showing records in Table using TO 2. The relationship between TO 1 and TO 2 is one of equality between the serial ID for Table. Let's assume that the field for the ID appears in Layout 1 but not in Layout 2. If TO 2 were a concrete instance of Table, I could use GTRR to get to the related record in TO 2 using Layout 2. But if TO 2 is based on a calculation, then GTTR is no longer usable.

So I figure I must (a) save the ID for the record in a variable while I'm still in Layout 1, (: go to Layout 2 using a calculation, and (3) find the record by searching for the ID using a Find script step. But of course the ID doesn't have a field in Layout 2, and I would prefer not to put one there for the reasons already outlined. Is there any other way to get to the related record on Layout 2? Maybe I misunderstood the advice I received in the earlier post about using Finds.

(Yes, this is indeed a follow up to an earlier post. I wasn't sure if responding to it would show up as a new post, so I started a new thread but also responded to the earlier post in case my original respondent has a solution to this new issue.)

First, I don't understand your basic premise. Why you need a layout based on TO 2? In general, it's best to base all layouts of a table on one "main" TO. Having a one-to-one self-join relationship based on serial ID also doesn't make much sense in most situations. Perhaps you should explain what are you trying to achieve with this method.

Next, it's not necessary to have a field on a layout in order to find records searching that field.

BTW, you might want to examine the attached file - it shows how to move a found set between TO's of the same table.

MoveFoundSet.zip

Instead of using generic names Layout 2, TO 1, etc. Use the real names of things.

OR

attach a copy of the database or a sample mockup.

And this does look like a followup question to the earlier Thread.

Please do not post a new topic when asking followup questions on and existing Thread.

Lee

Edited July 25, 201015 yr by Guest

Sorry, Lee, about creating an unnecessary new post. I see now that responding to the old thread would show up in Recent Posts. Thanks, too, for the suggestion about attaching a copy of the database, which I have just done.

Consultant: I think you may have provided a solution to my issue by suggesting that I base layouts of the same table on the same TO. Then a Go to Layout based on calculated name will take me to the same record, yes? In which case, no need for a Find. I'll recode and see if I run into any more difficulty. Many thanks for the insight!

I think I used separate table occurrences a while back to provide conceptual clarity and to reduce density on the Relationship graph. (You can see the attachment for relationships.) But the TOs Locations 2, Teams 2, etc., for example, can be folded into the table occurrences in the central cluster.

Note that I modified my earlier description of the problem to simplify things. What I was actually trying to do was jump from Locations 2 to Locations 3, etc., but I'm doing so in a script that uses variables based on calculations rather than concrete references to specific TOs. (My aim is to reduce wherever I can several scripts with the same action for different types of data to a single script. A worthwhile endeavour? I am certainly finding it challenging in a number of respects. I'm very curious whether experienced FM developers go for general and abstract or concrete and redundant.) Note that your suggestion about how to move to an unrelated TO of the same Table wouldn't work, because GTRR doesn't allow calculations for the "Go to related record from" part of the dialogue. That's why I am now relying on Finds. But if the TO is the same, even a Find should be unnecessary.

As for your point about avoiding self-join relationships, I do have a lot of those for the purpose of checking whether a user entered a duplicate of a field. I create a calculation that counts the number of records with the same field entry. Would a Find in the script be a better way to go?

Relationships.pdf

However, I'm running into one persistent difficulty. Most of my layouts don't include a field for the serial number of the record. That is because my users shouldn't have to think in terms of serial numbers.

Serial numbers are vital to any database. Whether the users ever see the RecordID is an entirely different matter.

I need that serial number in my layouts to be able to find records

Another false premise. You do not need serial numbers on a layout in order to find records by Serial Number.

Set Field operates on fields whether they are on the layout or not - as long as you are setting a field that is valid for the context. This script does not require Serial Number to be on the layout.

Enter Find Mode

Set Field [ Serial Number; 1234]

Perform Find

Edited July 25, 201015 yr by Guest

It's a bit more complicated than that here: I can't use a set field because I don't have a concrete field reference. The problem here is that in this situation I can refer to layouts and fields only by way of variables and calculations. I have been using Go to Object to set and navigate to fields, but there is no object for the ID on this layout. But your response nevertheless put me onto the idea of going into Find mode and setting the field by name instead of relying objects. Calculating the field name in this instance is a bit complicated, but it should be do-able. So thanks for putting me onto a solution.

My aim is to reduce wherever I can several scripts with the same action for different types of data to a single script. A worthwhile endeavour?

Up to a point - which I believe you may have passed.

As for your point about avoiding self-join relationships,

That's not what I said - I was referring to self-joins to the same record.

I create a calculation that counts the number of records with the same field entry.

Although that can work, I prefer to validate the field as unique.

If it is more complicated than that - you are very much playing in the wrong territory - as evidenced by your graph. This is a completely misplaced effort. Learn basic Filemaker first; and pay a qualified tutor, because you are not getting this figured out by yourself.

Thanks, all, for your very helpful advice and your frank comments. Despite appearances to the contrary, this exchange may have given me what I need to compact redundant scripts into more general ones. My first go at this is now functioning fine, thanks to your suggestions, but I will certainly take some more time to think about whether I ought to draw back from the precipice.

Although that can work, I prefer to validate the field as unique.

See:

http://fmforums.com/forum/showtopic.php?tid/176348/post/204677/#204677