I'm an old hand with FMP6, have done a fair amount of SQL, and have now been asked to develop in FMP9 Advanced. It's early days, but it's going well.

However the fm7 file format has some puzzling ways of handling relationships. I've looked without success for guidance on FMI's site for something that explains concepts such as base tables, anchors and the like. I've also looked without success so far on FileMakerMagazine.com's site.

Would appreciate some direction to docs that would fill the gap.

Appreciated,

Morley Chalmers

A key concept of FileMaker is that the layout you are on determines the context of your relationships and calculations.

A layout is based, not on a table, but on a Table Occurrence, which is an instance of a table on the relationship graph.

An anchor is not an actual FileMaker term, but is part of a popular methodology/philosophy of FileMaker design.

A couple of links for you:

Kevin Frank on Anchor/Buoy

The FileMaker Book (via a blog) Anchor / Buoy

Is there something specific that is puzzling you?

A couple of links for you:

Kevin Frank on Anchor/Buoy

The FileMaker Book (via a blog) Anchor / Buoy

Is there something specific that is puzzling you?

I've purchased the unlocked Permissions Template from filemakermagazine.com. Quite like it and most of what Matt produces. Followed his detailed instructions for moving the functions of the template (controlling which end user has access to what) into an existing solution.

Got right down to the end of it only to discover the fundamental relationship which pulls the current FMP current AccountName and puts it into a table of global fields is broken. Spend hours grabbing screenshots of Matt's setup and my own and comparing and finding nothing wrong anywhere, with one tiny exception.

When I go fix an imported lookup, the expected relationship isn't among the Related Tables list, rather it's among the Unrelated Tables, all of which are greyed out. Yet the structuring of the relationship is identical between the two files.

My colleague tells me it has to do with Context, the differences between relationships as in FMP6 and SQL and Table Occurrences in fm7 format. He says, "For me, it

is always context that is the problem." And proceeds to praise the Anchor/Buoy method of Relationship Graphs.

I want to go beyond just fixing this instance of a problem. I want to know the fundamentals so I won't blunder (too often) into this problem again.

Thanks for the links. Am proceeding now to check them out.

Much appreciated,

Morley Chalmers

... the fundamental relationship which pulls the current FMP current AccountName and puts it into a table of global fields is broken.

I haven't worked with that particular file, but two things strike me about that statement:

1. Get(AccountName) doesn't depend on relationships

2. Global fields can be referenced even when they're unrelated

Just want to chime in since you've hit upon why my tag line is, "Guaranteed, it's a context issue."

It seems every time I use Set Field, I have to make sure that I've chosen the correct context.

Study AnchorBuoy. Without it, I couldn't imagine keeping track of context in calculations and scripts.

Here's another good one on this topic:

Managing the Relationship Graph with Squids

test

Edited August 18, 200817 yr by Guest
test post by Administrator...

Here's another good one on this topic:

Managing the Relationship Graph with Squids

Very, very interesting. A radically different approach to Anchors/Buoys. Are you using it? Would be interested in hearing user experience with Jon Stark's Squids.

Kind regards,

Morley Chalmers

Stark was one of the first if not the first to write about Anchor/Buoy. I'm not sure what you mean by "radically different," it's pretty much the definition of A/B, although he calls it Squid. The terms are interchangeable.

Stark does say this in his Q&A though:

"To be clear, Squids and TOGs are not the same thing. TOG proponents avocate functional groupings, while Squids are strictly perpectives, devoid of any implied function."

My tendency is to use squids: always base layouts on squid heads, follow a similar naming convention etc. However, I also tend to relate the anchor TOs, because I want to take advantage of relationship bi-directionality where it makes sense to do so.