What is the best method to find duplicate table occurrence within a file?
In the Relationship Diagram, select one table occurrence, then press cmd/ctrl-u to highlight all other occurrences of the same base table.
Keyboard shorts (depending on OS). For MacOS, for example, command+U =
Select tables with the same source table
Is that what you meant?
Sent from miPhone
What I was hoping for was a tool recommendation to help find duplicate relationships on a very large and old system. Many files and tables and the graph is a cluttered mess so even selecting table occurrences of the same base table is hard. We have Base Elements but not finding an easy way to find duplicate TOs as we clean up years of stuff in multiple files.
In short . . . I want a silver bullet.
The DDR uses table occurrence names in most situations. It's always possible to generate links back to the base table but in most practical situations the context ( table occurrence ) is more important that knowing the base table. I've attached a PDF from my own DDR analytic tool that shows what the DDR is providing to us.
In your situation the question is, what is a duplicate? All but the simplest systems will have many TOs based on the same table. If the system is Anchor Buoy then it is extremely likely that there will be many groups of related TOs that are duplicated under different anchors. Taken out of context, those groups are all duplicates, but of course, you cannot take them out of context.
ditto. What is a "duplicate"?
I use the DDR (XML) and a simple XSLT to import the Relationship values into a table. This includes the file, baseTable and other information to "list" the relationships. This may be of advantage to see where the KEY fields are used and that may/may not help you to see what is duplicated and where.
Let me know if you want the XSLT. This is what I import from the DDR:
<FIELD NAME="RelationshipID" TYPE="NUMBER" />
<FIELD NAME="LeftTO" TYPE="TEXT"></FIELD>
<FIELD NAME="LeftBaseTable" TYPE="TEXT"></FIELD>
<FIELD NAME="LeftField" TYPE="TEXT"></FIELD>
<FIELD NAME="LeftFieldID" TYPE="NUMBER"></FIELD>
<FIELD NAME="predicate" TYPE="TEXT"></FIELD>
<FIELD NAME="RightTO" TYPE="TEXT"></FIELD>
<FIELD NAME="RightBaseTable" TYPE="TEXT"></FIELD>
<FIELD NAME="RightField" TYPE="TEXT"></FIELD>
<FIELD NAME="RightFieldID" TYPE="NUMBER"></FIELD>
<FIELD NAME="File" TYPE="TEXT"></FIELD>
Preferably do this on a backup copy: Open the relationship graph, select all TOs and set their colour to something plain like light grey.
Locate the TO of interest, press Ctrl/Cmd-U to select all other TOs based on the same table and change their colour to something contrasting.
If the graph is large and does not fit into the whole screen the zoom out until you see the whole chart and locate the coloured boxes.
Thanks for the ideas. Right Now I am looking at FMPerception as we have such a large and complex system that needs a lot of clean up.
You might mark your own answer as correct, so others know what you decided.
Here are some of first things that we do with a Relationship Graph that is a “cluttered mess”: 1. Arrange the Table Occurrences in a way that maximizes readability. Here is one of ours...https://community.filemaker.com/thread/168266#comment-622653 2. Implement a consistent naming convention (if there is not one already). If you go down that road, you will want to be careful not to break your code... http://nyfmp.org/2011/09/26/renaming-filemaker-code-objects-without-breaking-code/ A good naming convention might be all you need to find duplicates. It will also mean that the export to the DDR and the analytical tool(s) of your choice is more useful. The 3rd party analytical tools (we use a number of them) are useful in finding broken and unused objects which we usually remove in multiple passes. Hope that helps. Tony White
Retrieving data ...