So I have multiple instances of tables named things like:
Students
Students_additionalData
Students_additionalData_fromClassList
When I go into relationship manager and do a find for "students" I want to find the "Students" table, but instead it finds a random one of these, and I have to click back into the search field and hit search again.
In addition the highlight is super subtle, so I often have to use the up and down arrow to actually FIND what instance I have selected.
Is there some way with MBS or something else where I can:
search for an exact match of the instance name
make the highlight of selected instance more pronounced
MBS Plugin uses a "dropdown" when searching the Relationship graph, so you can search for "student" and then use the dropdown arrow to show all the matches and pick the one you want to go to.
• very, very handy !
• the highlighting in the graph is very subtle but I am sure that is up to Claris to change
Good tip. I usually just type until it gets the right answer, but the pulldown could come in handy.
The problem is it still doesn't jump to the correct one. See example below. It instead jumps to a random (well probably not random, but I'm not sure what criteria) table that starts with the word "Staff" and does a very subtle highlight.
Not being judgemental - Honest! But you might want to clean up the Graph a little. It will be difficult to find the right TO when things are stacked and somewhat randomly placed.
Cleaning up the Grph is not difficult - colapse each TO to the minimum - when you need to see the related fields you can always expose those for the TOG that you need to concentrate on.
• Select ALL (command + A on Mac) and then drag them all downward until you get a LOT of empty space at the top of your graph.
• now select a bunch of the related TOs and drag them up to the top... you might leave a few "behind" or you might grab a few that do not belong to the group but that is OK ... you can drag those ones individually.
• in about 10 or 15 minutes you will have most of your TOGs (Table Occurence Groups) together and not overlapping the other groups.
For Bonus Points you can then start organizing each of the TOGs from Left to Right (if they are Achor Buoy) and/or just keeping them in distinct "spaces"
Is that actually easier? I'm definitely down for trying b/c it's a BEAST. I started out with it nice and neat but it grows and grows.. but I'm not sure this is actually going to be easier for me to find things. Because it's anchor buoy this is just one of 8 anchors, and they all have dozens of relationships like this.
I feel like having a more consistent naming convention would actually help me too. For a while I tried making everything long and just including the whole relationship, and every join, but that got cumbersome fast.
OK you inspired me. I'm not sure if this is what you meant but I spent 2 hours (and a few crashes while editing??) and cleaned everything up, and tagged things with Emoji's as the first character followed by AnchorTableName. So for example if it's related to Sign-In and connected to the Student table it now starts with:
Student_Whatever
And this is what it is now named if it's anchor is the global table:
Global_Whatever
I think this grouping will make it easier to find everything... although having the AnchorTable name might be redundant since if you're on a page that's based off the Global Anchor you can ONLY see things that are global... I had that at the end of the TO name for some and the beginning for others and I moved it all to the start, but now I'm thinking that's backwards... grrr. LMK what you think if you have an opinion on including the AnchorTableName in the TO name.
However .... there is always an "however", right? ... I would not use any emojis because I would be too afraid of breaking something - e.g. use with an API or ODATA or SQL.
I honestly don't know how emojis work in other programming languages or for passing parameters. I also don't know what they do to sorting - you want to be able to pick things from a list in calculations and scripting and I would want things to sort A-Z and be together.
So, I hate to say it but I would remove them - maybe some other smarter programmes can chime in.
In my apps I use ANCHOR then anchor__BUOY_descriptorasneeded
• double underscore between TO's and a single underline if a descriptor is needed
Another thing to be careful about... if you are using JSON and/or SQL, and/or you are passing field names as part of script parameters, and/or filtering portals, etc. ... then these could easily break (!!!) when you rename things.
You will need to check that scripts and portals and any script parameters still work.
They probably will work in most cases.
Once you have settled on your naming convention and made your changes ... then I would stick to it, and not change any TO or field names in the future. That is tedious work and requires testing. I know this from taking over a few systems that needed updating.
Yeah I'm not renaming any fields or tables, or using Emoji's in there since SQL. I haven't had a problem with Emoji's in layout names or scripts so far and it REALLY helps my dyslexic self find things quickly and easily.
In terms of naming, the long names get very hard for me to parse with my dyslexia. I know that's not the be-all-end-all but if there are a bunch of long names together my eyes can't separate them. Still processing what to do here.
Hmmm... maybe use 5 underscores between the names and 2 between the descriptor. I only use a descriptor if absolutely necessary, but that is a personal choice.
• the long names in the relationship graph do seem to work in the calculation dialogues - see the picture attached.
Is this easier to read?
student_____gradrundown_____STAFF__capstoneAdvisor
Another thing to consider is to move all your main TOGs to the left and organize them top to bottom - rather than having some on the right. It all depends on what is most comfortable for you.
More underlines DEFINITELY helps. Good to know about the lengths. So many places in Filemaker cut things off. I'm REALLY excited about how Filemaker 21 now "remembers" columns widths for Manage Layouts... lol.
In terms of layout my screen is super-wide, so with this wide layout I can fit 95% of my TOCs on the screen, so it works super well... of course if I add more underlines it may no longer fit... lol.
PS: Minor note... I tried on two different computers and there's a bug in FMP 21 where if you hit command-A on the Mac when editing the relationship graph Filemaker hard crashes and you lose all the work you've done... I did it 3 times accidentally... doh.
Yikes! I had that happen once (at least) and it is not good.
I will search the Claris Community forum to see if others have reported the issue.
Also, do not use the "*" character - or any reserved character or reserved word.
I know you need a naming convention for these long names - maybe you could come up with some "standard abbreviations" (for your system) e.g. IMTR for ImportTracker and then perhaps a single underscore for the next part of the name:
Student____GradRundown____IMTR_TranscriptSummary____This isForWhatever
• as long as you are consistent you should be OK
• picking the right abbreviations can be a little tricky when you have a lot of these but you can use a text box on the graph (probably situated at the very top left of your graph) to describe what your abbreviations mean along with a short description of your naming conventions - this will be useful for your future self and for anyone else who might work on the system.
Here is a link to the help page for field naming - I think it mostly applies to Table naming and the TO's on the graph:
But you might want to clean up the Graph a little. It will be difficult to find the right TO when things are stacked and somewhat randomly placed.
Student_Whatever
