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
SeedCode’s Ann Kiser recently spoke to the Claris Beyond user group about her experiences running projects in Salesforce and how to use the Salesforce API
DayBack for FileMaker 19 works great in Claris Pro with no changes required. The older DayBack Classic also works in Claris Pro, but requires a few changes.
DayBack can now render a list of items needing to be scheduled. Users can drag items from this list into the calendar when they’ve found
Inline Notes in DayBack Calendar The latest DayBack extension adds an icon to your events when there is a comment present that matches your criteria. You can
Stay up to date with the latest news & examples from SeedCode
© 2023 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