Lesson 10: Anchor Buoy pt. 1


Hi, this is Matt with AppWorks and today’s video is going to be about Anchor Buoy, and comparing and contrasting that with the Spider Graph. What we’re really talking about is the approach within the relationship graph of having a spider graph, where you have one large structure with everything next to everything.

This other approach is Anchor Buoy, with table occurrence groups, where each set of table occurrences are disconnected from each other, and there’s a really consistent naming approach where its really easy to select something.

Why would you do that? Here’s an example. On the example Spider Graph database, where I want to add the phone number of someone who works in this organization, I’ll grab a number and put it on the graph. Grab the field called Phone, exit the layout, and it shows the same phone number for everybody. At a glance, I wouldn’t know that this is wrong, but if I change the phone number, everybody’s phone number changes. This looks like its right, but it’s actually not right, because that’s an invalid relationship for what I’m trying to get to. It’s really hard to know that because I have to go to the graph to research.

Let’s talk about Anchor Buoy – let’s try that same approach. Go to layout, add a field, put it on the layout. Here I have really consistent naming. If I look at my structure, the first thing I notice is I have related tables which is a small set – I don’t have every single thing. All the tables down here are unrelated – I could use them, but I won’t. I have a really consistent naming convention, where I have Company_Employee and Company_Employee_Phone. I’ll pull Company_Employee_Phone down, and I’ll see that the phone numbers are actually different. This is why Anchor Buoy is a really valuable tool and why it’ll save you a huge amount of time in most of your FileMaker databases. In the next video, I’ll talk more about the naming conventions and some of the more subtle points for how to do this.

Lesson 11: Anchor Buoy pt. 2


Hi, this is Matt with AppWorks and this is part 2 of the Anchor Buoy series, which will focus more on how to do it.

In this example, let’s say we’re going to add a Notes table to this CRM solution that we have here. So, if I take a look at the graph, I’ve already added the table, which is over here. There are 2 things I want to touch on – we talked in the other video how we only ever make a layout based on the leftmost occurrence. When I made this table, it automatically created a layout for it. I might want to have other things that hang off of note over time, like an audit log or something like that. The first occurrence is going to be the head of its own table occurrence group. I’m going to Option Drag it to make a copy, and connect it to Company. The way that I do this relationship – grab any 2 fields, hit Command O (Control O on a Windows), which opens up the edit relationship dialog. I find this much more useful to connect the fields together for the relationship than to try and do it on the little tiny graph by dragging the right field. This is going to be Company → ID to ID_Company. I’ll click change and accept that.

The next part is really important – it’s the naming conventions. If I just went to my layout now and tried to add a portal, it’s going to come up with my portal dialog – I don’t know if it’s Note 2, or which. That’s the only one that shows up – it’s not very clear looking at the graph what my naming convention is. I’ll go back to the graph and take a look at how I’ve done these other ones. The underscore character in a table occurrence has a very specific meaning – it means there’s a relationship here. If I take a look, I’ve got Company to Company_Employee to Company_Employee_Phone.

Every underscore only means one thing – that’s a relationship. In the more formalized approach, sometimes what I do is give a code – so, for example, I would call this one C__Company (double underscore). The double underscore is the head – after that I just use the single underscore and everything after that is the group. I’ll convert this table – it’s a fast thing to do. This makes the names shorter, so if you have a lot of relationships, having that shorter code is definitely nice. The thing we have in the middle – the right-most word is generally the name of the table that it is referring to. This is the employee table, sales rep table, etc.

In this case, the employee and sales rep table are both connected to the person table – they are two different instances of a person. The Note table, if I double-click, C_Note. I see crossing lines – crossing lines drives me crazy, so I’ll drag my tables so that this doesn’t happen.

Now I have my graph working! If I click Ok to save this, I’ll see if I add a portal, that it’ll be very clearly named, so I can see that my top table is here and all my related fields are underneath. If I choose C_Note and click ok, I’ll see fields on the left that I can start adding in. I can choose the specific fields that I want, which will be C_Note::Date, C_Note::Note and C_Note::IsDone, which is a field I use to track if a note is complete or not. Click ok.

I also can’t make a new record – I’ll go to my graph and fix one thing. That is to click the box on the right column on the bottom that says Allow creation of records in this table via this relationship. I don’t really ever click this on the leftmost column, and I very rarely ever click on the fields to Delete or Sort. Now I should be able to create records with notes. I’ve completed adding a portal, I’ve added labels, and shown an easy way that you can use Anchor Buoy in your solutions.