I'm looking for help to better understand the importance / difference of right and left side toc. Thank you for any advice.
In reference to what? Table of Contents?
FileMaker doesn't have a TOC object, you build your own objects that would serve that purpose.
In that case, what sort of advice are you seeking concerning positioning, since it's custom?
In any case, the recommended place to put navigation objects is in the top or bottom navigation body parts. Filemaker does not have columnar body objects, they are stacked vertically, so one usually doesn't even put in left or right navigation.
I’m sorry, new to this, didn’t make myself clear.
On the relationship graph in a relationship between two tables, is there any benefit or difference between the table on the right or left of the relationship?
That's more like an ERD, not a TOC.
The chart is elastic, so it doesn't matter where you place the tables, the line connecting them and the dialog that controls them will specify the parameters of that relationship.
If you drag a table to swap positions, and open up the dialog again, you'll notice the left and right sides of the dialog have switched. This is just based on their position in the ERD, it has no bearing on how the relationship itself behaves.
Mike’s right, of course - there are no true “sides” to relationships in FMP. However, if you are using the anchor-buoy model, there can be an implied direction. That is, the base table of a table occurrence group (TOG) is generally on the left; that is what layouts gets based on. Then you can look out to the right to see data related to the records in the base table. Frequently the A-B model also uses a naming convention that appends names, sort of like this:
Company -< Company_Contact -< Company_Contact_Phone
As Mike said, there's no intrinsic difference as to whether Table Occurrence A appears to the left or right of (or above or below, for that matter) Table Occurrence B. Debi's also right that there can be an implied direction, and I make use of that all the time, with my main TOs in a column down the middle of my Relationship diagram, with globals and saved values to its left, and dependent TOs to the right. Here's a super-simple one from my "Quotations" file:
Since you asked for general advice, let me say a good word about color coding your TOs, so you can tell at a glance which table each one is based on.
I've also adopted the convention of having my keys begin with some kind of abbreviation of the table name, then having the character string "Seq" (for sequence number), and ending with either (a) the digit "1" if it's the primary key for that table or (b) the initial of the table it occurs in if it's a secondary key. You will find that some kind of similar convention is of great value when you get to searching Database Design Reports generated by FileMaker Pro Advanced. The important thing is to pick a naming convention that works for you and use it consistently.
Also, in case you haven't already discovered it, you can edit the specifics of a relationship by double-clicking on the relationship operator box:
That'll open up a dialog that presents you, at the bottom, with 3 options for each side of the relationship. Those can be of immense value to you once you get the hang of them:
Note also that "one way" relationships are possible in FileMaker.
If a match field on one side of the relationship is not indexed (typically an unstored calculation or a global field), You can match to records from the context of the table occurrence with the unindexed match field to the table occurrence with the indexed match field, but not the reverse.
Say you have this relationship
TableA::UnindexedField = TableB::IndexedField
You can base a layout on TableA and put a portal to TableB on it. but trying to put a portal to TableA on a layout based on TableB will not work.
The relationship graph identifies fields that are not indexed by making the "connector" at the end of the relationship line a "T" so this is something to look out for.
You might also find this old, but still relevant tutorial on table occurrences helpful:
Thank you Phil,
So to clarify my understanding,
LayoutTable::CalculatedDate = TransactionsTable::Date
will work ok but
LayoutTable::StaticTrue = TransactionsTable::CaculatedProcessed
will not work?
Another way to think of it is like plumbing, you can follow the pipe in any direction, and you can also follow multiple depths, e.g. you can use a sub-relationship in a portal and as long as you follow the pipeline it will work.
The only limiting factor is that you can not traverse towards a global or unstored calculation field, you can only traverse away from a global or unstored calculation field to a stored (indexed) field.
I hope that another explanation has helped.
"So to clarify my understanding,
LayoutTable::StaticTrue = TransactionsTable::CaculatedProcessed"
It's not a matter of whether or not the match field is calculated but whether or not it is indexed.
Than you Phil, and everyone else who has responded to my first post.
Your help and advice is most appreciated.
Retrieving data ...