The second part of his solution uses this fact and goes on to lookup a count of the self-relationship in order to serialize sub-records (people working for a company, etc.). I'll have to get to that next month. It's pretty tricky. Let's just look at marking first entries for now, using my file Import (different from last month's Phone.fp3).
First you'll need a self-relationship based on a unique identifying field. It could be a concatenated calculation field, type text, using the name fields (First & Last), or it could be any identifying ID field, if you have one assigned. We don't, so I'm using the Concat field, with the self-relationship, Concat= ::Concat.
Create a field First Lookup Not, so named because it looks up nothing for the first entry. Click the Options choice to see the Auto-enter dialog, then click the box for Looked-up. In the next dialog choose the Self Concat relationship in the drop-down box. In the box for what to enter if there's no match click "use," but don't enter anything.
For the field to lookup if there is a match I chose the simple Constant=1 field.
First Lookup Not will be empty for every first entry, and have 1 in it for any duplicate entries. For our purposes, it would be better to have the opposite, a 1 in a field and nothing in duplicate entries.
So make a field, First Lookup, type calculation=
If (IsEmpty, First Lookup Not, 1, "")
Having the 1 will be useful. Since it is indexed, a simple relationship from the Constant=1 field to the First Lookup field will allow you to quickly Go To Related Records, showing only the first entries on list views. Portals using the relationship will also show only the first entries. It is by far the fastest most reliable way to control visibility.
There are a few cons however. Lookups are dynamic in a funny way; they change when the key (the field that the relationship is based on) is changed, but not when the related field changes (like regular related fields do).
If you delete that first entry, the next one won't change to take its place, so there will no longer be a marked First Lookup for that name; therefore it will disappear from your filtered lists.
If you duplicate a first record the 1 will duplicate, so you'll have two first entries for the same name.
If you cut one of the names out then paste it back in, or even edit it, the First Lookup mark will be deleted (only if there is a duplicate record), as the name is part of the key. It causes a Relookup on the relationship, which is now valid, since there's more than 1 record with the same name.
The very worst, however is if you do a Relookup on all the records, using the Concat field (which you might be tempted to do in order to update some other field that also uses the relationship in a lookup—but don't do it). Since there is now a valid relationship in all the records that have the same names, all of those First Lookup marks will be wiped out.
Even if you do, all is not lost. Going back to last month's article, we can use the old scripted method of marking first entries to fix it. On the First Lookup Not field, use the self-relationship in a Replace operation, calculated result,
= If (Serial ID = Self Concat::Serial ID, "", 1)
You can't use it on the First Lookup field because it's a calculation, but it updates. I've included this Replace First Lookup in the Script Menu.
Warning: Make sure the field First Lookup Not is on the layout in this case. It can be hidden, but it must be there for the Replace to work.
By the way, I know this whole business of marking the first entry in this way is unnecessary in a simple phone type file, where you only have one record for each name. It is very useful in many other files, even phone files if they have multiple entries for each company, such as in Serialize by Category. The Import file had already been built for the second part of the article; I grafted this little operation into it so you could see an example in a simple file. Eventually we'll get into a Job Service file where there are always multiple entries and marking is essential.
Websites mentioned:
Send comments, questions, toys to Fenton Jones
FileMaker Pros, John Mark Osborne