In table one there is a "full_name" calc field that combines the first and last name.

In table two there is an "extras" field that has a value list to choose from the "full_name"s of table one -- once chosen sucessfully triggers several lookups in table two, as it should.

There is "relationship1" set up in table one to table two, full_name::extras.

In setting up the script step "go to related record" in table one, the "relationship1" is seen, the option for using the external table is seleced and the layout for table two, form, is selected as well.

When trying to execute the script, there is a message that the operstion could not be completed because the target is not a part of a related table.

What am I missing?

Hi Geoffrey

The layout is tied to a TO from which the GTRR works from, if the linking lines belong to another pair of TO's do you need to go to a layout which is tied to this pair!

--sd

Hey Søren!

Thanks for the response but Ihave to admit I don't understand your observation among other things, you abbreviations...

Do you have a recommendation?

Best:)

TO ....stands for Table Occurence

GTRR ...stands for Go To Related Record.

But the first abbreviation ought to have popped up under your nose when you read "Migration Foundations and Methodologies" at the point when you upgraded

--sd

I don't mean a recommendation on recognizing abreviations, very funny,ha ha ...

What I don't understand is why FM will allow you to complete the script step, GGRR, where it inherently sees the relationship and then when you attemp to use it, says its unrelated?:

ScriptMaker does not know where you will be when you call the script - so it's up to the developer to make sure the GTRR step is valid in the context.

Exactly as Comment says it, but you were used to a script per file under fm6 ...but if had paid more attention to page 57 in the whitepaper would have stumbled over this:

In previous versions of FileMaker Pro, the focus or context of a given operation was implicit in the design, since FileMaker Pro has supported only one table per fi le and only one window per fi le. These facts, coupled with the FileMaker Pro single-threaded architecture, ensured that the developer was always aware of the precise context of where a script was functioning. A script would only operate on one window of a given fi le because that was the only window that could exist.

--sd