how to go from ERD to interface in FMP vs MSAccess

[enki]

hello, I am transitioning over from MSAccess to FMP8.5 Advanced and am trying to understand what is the structure of FMP development.

Lets assume the msaccess steps are:

1)create an ERD

2)build tables

3)create queries based on tables

4)display queries or tables in a form.

How do i do step 3(create queries- involving several tables) and 4(display layouts from many tables) in Filemaker?

How does one tightly control a cascading entry across say 5 tables (via serially connected tables [not 5 tables connected in parallel-this i can do.]).

I don't see how to create a query that integrates 10 tables using joins/union/ selects. My portal can show me a table 2 tables away but not 4 or 10.

Also sql queries are an enigma. How do i query 6 distantly related tables at once?

What FMP philosophies am am missing?

Is there some link that has an overview of design approach for filemaker?

Do you see where i'm going with this? The philosophy of going from ERD to interface in FMP- i don't see spoken of or written about. The overall flow is unclear to me, there is plenty of detail on specific problems/solutions. But i'm looking for a broader perspective. Any insights would be greatly appreciated, and i think all novices would benefit from a big picture overview.

thank you.

[T-Square]

Enki--

Welcome to the Forums!

I transitioned from Access to FM a while back, so I can commiserate with you. It is sometimes tough to get your head around FM's ways...

In a nutshell, you want to look at the Relationship Graph (RG) very closely. In my mind, it serves a kind of hybrid role, and handles a lot of what you are used to seeing in both the Access ERD Relationships window and the individual query windows.

Both Forms and Reports are handled in FM as Layouts; a layout is based on a Table Occurrence (TO), which is created on the RG. A given data table can be represented on the RG many different times, to reflect the different contexts that you would have seen in MS Queries. Thus, a Client who is related to an Invoice will appear on the RG (maybe called InvoiceClient on the RG) in addition to a Client who is related to a Company (maybe called Employee on the RG).

WRT the SQL issue: to retrieve data from a distant table, you build the relationships (on the RG) and then refer directly to the fields at the other end of that chain. FM handles the querying as it goes.

Portals are FM's version of Access' Subforms, although in FM there is no separate subform object you can edit...

I hope this heads you in the right direction, and I sincerely hope that my descriptions are accurate, true, and clear.

David

[Genx]

This is actually a really, really good overview of the differences David.

[enki]

Thank you T-Square, your description. It jibes well with the data-tunneling interface section of "Missing Manual."

Do you, (or anyone) know of a walkthrough website that addresses data tunneling and the virtues of Global Fields? It is not clear to me how Global Fields fit in. "When not to" i can learn from as well, but no one seems to go there.

Thank you though for your reply i am trying to figure out the methods based on the abstractions.