Naming Conventions

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?

Featured Posts

Follow Along

Stay up to date with the latest news & examples from SeedCode


  • 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.


  • Simon Danielsson

    For about 5 years I have used the following.


    1. Capital letters for primary key only
    2. Note the underscores
    3. The global field is a numeric one

Leave a Reply

Your email address will not be published. Required fields are marked *

Check out some of our other posts ...

Improved Resource Selection

We’ve made some big changes to how you filter and assign resources when editing events in DayBack. These changes will make it much easier to

Suggesting Appointment Slots

Show Available Slots that Match Multiple Criteria Schedulers often look for gaps in their schedules to find the open resources for each opportunity. But sometimes,

Introducing Draft Settings Mode

Following up on this idea that people stretch themselves when they feel a little safer, we’ve been very focused on the customization experience for DayBack

New Longer Timescales for DayBack

Resource Scheduling Swimlanes You can now extend the pivoted scheduling view in DayBack to show items by week instead of solely by day. This lets



Stay up to date with the latest news & examples from SeedCode

© 2024 SeedCode, Inc.