1 of 1 people found this helpful
You're probably a 1 in 100 or 1000 developers that has an issue like this. But if you're crying about it, you're not thinking productively for a solution. Certainly over the past 18 years since FM3 was released, you've had plenty of time to adjust your files, search for a solution, or even convert to another platform? This question seems out of place over 15 years after this change was made.
Here's a $125 investment that will change the way you develop in filemaker:
The developer assistant allows you to search and find things in the relational graph (as well as a lot of other places). While it's not a utility that turns the relationship graph into a 20 year old version you're pining for, it does offer a good solution to your issue.
If this is the only thing that's holding you back from loving development in filemaker, certainly $125 would be worth the investment.
1 of 1 people found this helpful
I can see that point that it would be nice to have a text- or table-based way of seeing/editing the relationships graph. But I wouldn't wan't get rid of the visual graph… just in addition to.
There are certainly many things that could be improved about working with the graph. My guess is that you are working on solutions that have grown (and grown, and grown) from something simpler and not had the planning of being a larger, "serious" FM solution, as you say. (Raise hand: GUILTY!) Or that you are inheriting solutions that other developers have set up without as much organization as you would like.
I didn't discover (and then didn't fully understand it correctly) the anchor-buoy system until I was too far along in my second major system. Now I really want to go back and re-work them… but they work now and the time required to work on it off-line just isn't there. Sometimes it seems like the effort and duplication of TOs required to plan and stick to a system like AB isn't worth it, but once you get a large enough system, you can go to the graph with NO MORE TEARS!
This doesn't directly answer your question, but one thing that really helped me start managing the relationship graph (and therefore relationships) much better and more easily was Ray Cologon's article 'Approaches to Graph Modeling' http://www.nightwingenterprises.com/Resources/approaches_to_graph_modeling_en.pdf
I find that by grouping TOs into funtional blocks and using colour and labels makes things much easier to find/edit.
(& on Rays article)
-- sent from my iPhone4 --
I should have added - I do not miss the old (pre FM7) way of handling relationships at all. If I wanted to go back to the dark ages I would fire up one of my old Z80 based CP/M machines and use dBase II with 8 inch floppy disks (yes I still have them).
I can see the need (in special circumstances, especially upgrades from older solutions) for a basic list of relationships, but in those situations I generally use Base Elements (but of course there are many other solutions).
I expect this is the issue, moreso than the list vs. graph approach. Organization makes things easy to find.
While I'm not personally a fan, Shawn's suggestion of the anchor-buoy model is often helpful to folks who are more comfortable with the pre-7 relationship structure, since it mimics how things used to work in the one-table-per-file days.
thank you very much for your help.
You are right! My question comes out many years after the change.
But I can say for sure that if you have to develop a solution that manages everything inside a factory, from phone calls, manufacturing, controlling workers' efficiency, custumer support, a web site for clients and providers, invoicing, payments, statistics, automated daily assignments of to-dos to human resources, newsletters based on previuos orders, google calendars for all workers, create XLM reports, a system of real time messages between co-workers, and so on...the graph tab of relationships can get you seriously nervous; in addition, as you can wonder, the solution is updated witgh new functions almost every week.
That said, since relationships are reported in the html summary of the solution, it would be easy, I think, for FM development team, to give us a text active list of relationships.
I'll try Dracoventions solution ASAP, and in any case, I would never change my DB development platform: FM has so many very good things in it!
But the graph of relationships is a lack.
Thank you very much for your help; maybe I'll give up with crying
Been there, done that.
My best suggestion is that a solution that old probably needs a complete overhaul to correspond to the new paradigm. You’d be amazed how much you can gain. I’ll give you an example:
Several years ago, I inherited a training database. Originally developed in the version 5 days, the solution had over 70 files in it, all cross linked and connected. One script alone, responsible for selecting an item from a menu, printed out at 151 pages (by the time you jumped into all the subscripts in various files it called). So, we set out to move it to the consolidated .fmp7 format (using Separation Model). When done, that same script - with identical functionality - printed out at a page and a half.
You’ll thank yourself in the end.
Not to derail the thread too much (I think this is still relevant), but just curious what organizational method you prefer. I'm still learning and experimenting, so I'm curious the pros and cons of different methods. I have talked to some developers locally who consider anchor-buoy to be the only viable option. But as long as you are using some kind of convention/standard, then it should not only make it easier for you to find things, but it will also make it easier for another developer to assist or pick up the project. Remember that "another developer" could also mean "future you" x years down the road!
Anyway, if you could shed some light on why you aren't a fan of AB, and what you use instead, I would find that input valuable. Thank you for all that you contribute here!
Some of the pros and cons are outlined in Ray Cologon's article linked above (page 10), but in general, I don't prefer it because you end up adding more TOs than you really need.
Take a look at the relational chart for seedcode calendar and you'll be blown away (I think the entire file uses 3 or 4 tables total), this is the transcendental model Ray refers to in his article (page 21).
With the advent of ExecuteSQL, you can most likely trim a good chunk of TOs out of your existing files when you convert to 12.
I'm more of a fan of Cluster/Satellite (page 13), as I can group things together by section/feature/area. However I hybrid it up with human frailty (page 19/20), to make sure my clusters are labelled appropriately.
Sorry, I know you were looking for Mike Mitchell's response, but I thought I'd chime in as well to give you multiple opinions.
I have talked to some developers locally who consider anchor-buoy to be the only viable option.
That's the one thing to guard against: there are no absolutes. When we train interns and "non-structered" experiened FM Developers, A/B is a very natural model to get into. Working with different levels of developers it is an easy standard to understand and maintain. And the main pain-point of duplicate TOs is one that is easily maintained, especially with the use of the ExecuteSQL() function.
Having said that, we do challenge our develpers continously to "question" the model and look for improvements,
But we do not want to stray into the realm of dogmas.
No need to apollogize! Multiple opinions are exactly what I'm looking for. I'm willing to hear from anyone named Mike!
While absolutes are a little risky, I’m not a fan of anchor-buoy because:
1) As Mike B. pointed out, it creates a lot of extra TOs. That introduces extra overhead into the graph. (Minor concern.) It also creates a longer list (often, a MUCH longer list) when scrolling through the list of TOs for calculations (more significant concern), because it introduces more possibility of confusion.
2) More importantly, it locks you down to a single-direction flow in your relational model. One of the biggest advantages of the Relationships Graph is the possibility of bidirectionality. A-B kills it dead.
As for what I prefer, I tend to like the Cluster-Satellite model or the Flotilla model. Depending on the complexity of the project.