Is it possible to go to related records table in the other file, which is not related directly.

[Megalo]

Hi, I'm a filemaker user who have been using for almost 5 years.

Now, I'm trying to make data tables and layouts separate into different files.

For example:

i)

"Table A (for Layout Customers)" belongs to "File 1.fp7"

"Table B (for Layout Products)" belongs to "File 1.fp7"

"Table A" and "Table B" are related by the field called "serial_id"

ii)

"Table A" is placed in "File 2.fp7" as Table Occurence Group.

"Layout Customers" belongs to "File 2.fp7", and shows "Table A"

iii)

"Table B" is placed in "File 3.fp7" as Table Occurence Group.

"Layout Products" belongs to "File 3.fp7", and shows "Table B"

Question:

When the found set of "Table A" is constrained with its "Layout Customers" in "File 2.fp7",

how can I go to related records of "Table B" with "Layout Products" in "File 3.fp7" ?

Any good ideas???

[Vaughan]

Back in the ye olde dayes (FMP 6 and earlier) the process would be to go to the related records in the first file, then from that file go to the related records in the second, etc.

These days, the actual location of the data is irrelevant. Just create a layout in the current file based on the external data source, and switch layouts.

[Megalo]

Thanks for the reply.

It's usually solved by "Go to related records",

but in this case "File 1.fp7" only has tables. There's no layouts.

plus "File 3.fp7" only has its own layouts without any table.

It only refers external table B in "File 1.fp7"

So I cannot press the check option to use "Use external table's layouts" to go to Table B from Table A.

since "File 1.fp7" doesn't have any layout.

I'm really struggling :sad:

[Megalo]

Can anyone tell if it's possible or not?

[Vaughan]

I have already posted the solution:

Just create a layout in the current file based on the external data source, and switch layouts.

[bruceR]

Back in the ye olde dayes (FMP 6 and earlier) the process would be to go to the related records in the first file, then from that file go to the related records in the second, etc.

These days, the actual location of the data is irrelevant. Just create a layout in the current file based on the external data source, and switch layouts.

Well; no.

GTRR does not work with the separation model.

If you have a data file; and say a contacts interface file; and an invoice interface file; you cannot go from Contacts to their related Invoices. Generally part of the point of the separation model is not to involve the data file in scripts.

[Megalo]

Well; no.

GTRR does not work with the separation model.

If you have a data file; and say a contacts interface file; and an invoice interface file; you cannot go from Contacts to their related Invoices. Generally part of the point of the separation model is not to involve the data file in scripts.

Thanks for the answer.

so it means what I said was impossible to do with data-layout separation model.

Right?

[comment]

I don't see why you couldn't do GTRR in the interface file. I cannot understand your examples, but if you have a Data file with a Parent table and a Child table, and an Interface file with no tables, you only need to place the tables on the RG of the Interface file and define a relationship between them.

[Megalo]

I don't see why you couldn't do GTRR in the interface file. I cannot understand your examples, but if you have a Data file with a Parent table and a Child table, and an Interface file with no tables, you only need to place the tables on the RG of the Interface file and define a relationship between them.

Thanks for the reply.

As I wrote in first post, Interfaces are also separeted into 2 files.

I cannot mix them together, they have to be separated.

So in this case, it's impossible. isn't it?

[comment]

As I wrote in first post, Interfaces are also separeted into 2 files.

As I wrote in my post, I don't understand your first post. In any case, you cannot go to related record if there is no relationship, Relationships defined in other files are irrelevant for this purpose.

You can have as many interface files as you want, but each interface file can only control the tables that it interfaces to. If you have two interface files, each controlling one data table only, then you have two flat table solutions - not a relational database.

[Megalo]

As I wrote in my post, I don't understand your first post. In any case, you cannot go to related record if there is no relationship, Relationships defined in other files are irrelevant for this purpose.

You can have as many interface files as you want, but each interface file can only control the tables that it interfaces to. If you have two interface files, each controlling one data table only, then you have two flat table solutions - not a relational database.

I'm sorry for lack of my explanation.

I made drawing(.png image) to explain the situation clearly.

http://uploader.saku...src/up53372.png

Please check this out.

I hope it helps understanding.

[comment]

Well, that's exactly what I described when I said:

If you have two interface files, each controlling one data table only, then you have two flat table solutions - not a relational database.

In theory, it's possible to do a series of GTRRs to get to the "related" records in the other interface file, using the relationship in the data file along the way. In practice, it's the equivalent of breaking a wall instead of walking in through the door.

I can't imagine why would you put such restrictions upon yourself. It doesn't seem to serve any purpose - other than making things more difficult.

BTW, I don't see what "the found set of "Table A" is constrained" has to do with the problem of GTRR.

[Megalo]

Well, that's exactly what I described when I said:

In theory, it's possible to do a series of GTRRs to get to the "related" records in the other interface file, using the relationship in the data file along the way. In practice, it's the equivalent of breaking a wall instead of walking in through the door.

I can't imagine why would you put such restrictions upon yourself. It doesn't seem to serve any purpose - other than making things more difficult.

BTW, I don't see what "the found set of "Table A" is constrained" has to do with the problem of GTRR.

Thanks for the reply!!!

The reason why I wanted to make it that way is because I want to make all the interfaces separately depending on its purpose.

http://www.rupan.net/uploader/download/1313974143.zip

I uploaded sample files.

Please extract the files, and open file2.fp7.

First of all, go to find mode, and search with "serial_id = 1"

then I'd like to go to related records of Product Table with file3's interface.

[comment]

I don't think we are making progress here.

I want to make all the interfaces separately depending on its purpose.

Well, if the purpose of the interface is to do GTRR, then it should interface to both tables.

[Megalo]

I don't think we are making progress here.

Well, if the purpose of the interface is to do GTRR, then it should interface to both tables.

Thanks sir.

I'll give up to archive going to related records with using external interface.