Displaying portal info table occurances rather than original table

[Hurlz]

My problem is this:

I have a range of related tables:

1. Species related to Permits
2. Species related to Ethics Applications
3. Species related to Research Projects
4. Projects (and Permits and Ethics Applications) are all related to other tables (eg people)

Setting up the many-to-many relationships for these, FM creates new table occurrences for Projects (Projects 2) to relate to Species and for Permits (Permits 2) to relate to Species. On the Species layout with portals for each of these all works. Each portal shows the records to Species from Projects (2), Permits (2) and Ethics Applications (master occurrence). 

However, when looking at the related record in Projects or Permits for a specific species, there is no related record showing. This is because the layout is set to show records from Projects or Permits, not the 2nd table occurrences of these. If I change the layout to show data from Projects 2 or Permits 2, all works, except the date from Projects or Permits (original occurrences) of course won't show.

Hope that make sense!

[rwoods]

Hi Hurlz

Someone else here may explain this better, but just in case you are sitting there waiting for a response, here goes!

FileMaker doesn't allow two 'paths' on the relationship graph to link any given two Table Occurrences (TO's) as it would lead to two different ways of calculating which records are 'related'. Therefore FileMaker will create new TO's automatically when it needs to prevent this, and it will call them things like 'Permits 2'.

From your point of view, this is not great as the naming of that TO doesn't give you any clue as to what to expect from the relationship that leads there. Most FileMaker developers use some form of the anchor-buoy method of creating and naming TO's. Very simply, this means creating a TO for each source table that you will use as the basis for any layouts based on that table (the 'anchor'). You then create TO's for any related tables that needs to be referenced from that source table, and you name them in a meaningful way (the buoy's). e.g customers_SALES_forThisCustomer would be a good name for a TO based on your SALES table, that is used  exclusively for when you wish to refer to, or display, sales that relate to a given customer.

You would never base layout who's source table is the SALES table on that TO though, you would have a separate TO for that (probably called just 'Sales'). And you would never create a relationship from any other TO to this 'buoy' TO, as that would have a confusing meaning.

This method means you have a 'starting' or 'anchor' TO for each of the tables on which you need to base your layouts, then lots of 'buoys' linked those anchors. You do end up with lot's off TO's that are based on the same table, but this is a compromise of the anchor-buoy method that has been discussed a great deal.

So if you wish to follow this method then you need to create some 'Anchors' for your tables, then create (or rename existing) 'buoy' TO's to give meaningful relationships from you anchors.

Did that actually come across as simple??!!

[comment]

7 hours ago, Hurlz said:

If I change the layout to show data from Projects 2 or Permits 2, all works, except the date from Projects or Permits (original occurrences) of course won't show.

There is no of course about this. It is simply incorrect. For local data, It doesn't matter which occurrence of the base table the layout is based on. However, you must make sure that the fields you place on the layout are coming from the same occurrence.

Is this a good solution? I don't know, probably not. It is very difficult to follow your explanation. I suspect there is a broader question here: what is the best way to organize the relationships graph. @rwoods already gave you one suggestion. You will find more here:
http://www.nightwingenterprises.com/Resources/approaches_to_graph_modeling_en.pdf

and also:
https://www.seedcode.com/filemaker-selector-connector-basics/

 

 

[Hurlz]

Thank you rwoods and comment. rwoods, that did make sense.

I apologise that my explanation wasn't very clear. I read the literature linked to and watched the anchor buoy videos to check I was working with this principal correctly - turns out I was. However, once the relationships in my database get somewhat complex, with interactions in many directions, my relationship table and TOs get messy, and hence portals don't look up correct information - I'm obviously getting confused.

I have put together a basic schematic which I hope will more clearly convey what I am trying to achieve. I also attach a recreation of the database in a simple form (minimal fields, no fancy layouts) with the beginnings of my relationship table and TOs which might help demonstrate what I'm trying to do and where I'm going wrong.

Sorry - haven't done anything this complex before. Your help is much appreciated.

H

HVWC anchor-buoy issues.pptx HVWC example.fmp12