There were some great discussions at FileMaker Bootcamp (thank you Russell Kohn, Lee Lukehart, Allen Imbarrato, and Bob Majors) along with a spirited discussion of naming conventions.
Jonn Howell proposed these conventions (where CON is his abbreviation for “Contacts”)…
___kp_CON primary key
__kf_CON foreign key
_kg_selected_CON global key
What do you think of that?
End of Content.
Stay up to date with the latest news & examples from SeedCode
See When Assets are Passing by Unscheduled Jobs Showing unscheduled items on the map lets you see when a route is passing close to jobs you need to schedule. As you click on each truck, you’ll see it’s route for the day and find unscheduled jobs that would be good
Seeing Availability at a Glance We recently customized DayBack for a customer who wanted to consolidates all the decisions of team assignments into a single screen. When a dispatcher clicks on a job, they can schedule the entire field team (technicians, lead, vehicle, departure plan, and equipment) without leaving the
A number of customers have repurposed the unscheduled sidebar in DayBack as a waitlist. Schedulers can drag eligible appointments from the sidebar into their schedule when there are cancellations.
We often see folks struggling to schedule both crew membership and crew assignment. This is particularly tough if crew membership can change with the different roles required on different jobs. The interface below helps a great deal. You can see the crew leads, with red icons, and the crew members
Stay up to date with the latest news & examples from SeedCode
© 2026 SeedCode, Inc.
7 Comments
I really don’t understand the desire to put the keys at the top with leading underscores. We tried that early on when 7 came out and I hated it – it’s in the way when the user is exposed to a field list in sort or export dialogs and it doesn’t match any other naming format for the rest of the fields. I know it puts the keys within visual range when connecting TO’s but I find that it doesn’t take much longer to just a line between the two TO’s (using any fields) and edit the relationship. Each field list has type-ahead making it easy to jump to the keys with a zk__ prefix. The __p suffix idenitifes the primary.
Do we need to specify the table for the primary key? Just using ___kp gives you the ability easily abstract the primary key.
True Jason, but I kind of like seeing those prefixes in calcs and layouts so I know if someone has grabbed the wrong field. Though I have to admin I almost never see primary keys on layouts.
BTW. Dan Stein reminded me that using a prefixed underscore in FMP 10 causes an ODBC XML parsing error. Something to keep in mind.
John the ‘_’ ODBC XML Parsing error is why we moved to aa__PKI_Contact_ID_n several years ago and normal use fields being Contact_Name_First_t while developer and utility fields get the zz_ or zz_UT_ treatmeant to push them to the end.
I like Simon’s a bit better. We prefer easy to read keys. I do like the triple and double underlines for the key sort order.
Given the example above we use this:
_ID for the primary, no matter what table it is in.
_IDContact for a foreign key.
_IDContact.Selected for a global key.
We’re want to make it easy to understand, read, and use.
I use the Table names. I guess the underlines would help to put all the Id in the beginning. I am not sure why the foreign key has one less Underscore.
Oreste
For about 5 years I have used the following.
__id__CONTACTS__p
_id__contacts__f
_id_contacts_selected__globN
1. Capital letters for primary key only
2. Note the underscores
3. The global field is a numeric one