Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Updating to include multi-key field prefixes


No Format
CLIPBOARD (is a reserved temporary global field)
id (is the primary key in all tables)
id_Tablename (is a foreign key)
idList_Tablename (is a pseudo-schema field for multi-key values related to solution schema)*
keys_Tablename (is a utility field for multi-key values used for UI specific functionality)
FunctionalArea » Tablename
@Tablename (is the name for developer table occurrences)
Tablename: Layout Name (form|list)
Script Name
Script Name ( with ; parameters )
title* Pseudo-Schema

FileMaker Pro provides a unique feature called a multi-key - not to be confused with a compound, or more commonly, a concatenated key. Wherein a normalized data structure will typically use a singular key value for each and every record, FileMaker provides the ability to store multiple keys, hence a multi-key, list of values within a text field. Because of this feature, it is possible to create what calls pseudo-schema. In the rest of the database world, this approach may not be considered valid, where isolated within the FileMaker world results in a feature which is heavily used by developers. While not suggested for normal use as part of your schema within a FileMaker solution, multi-key values for the purpose of maintaining relational structure amongst data would use the prefix of idList_ as opposed to the more utilitarian, or more specifically for the UI, keys_ prefix.

titleDeveloper note

The primary goal of these naming conventions is to create highly readable code. Concerns related to brevity are superseded by clarity and maintainability. These naming standards are also specific to FileMaker Client development. They do not address Web, Mobile or SQL based deployment. For more information related to these aspects of FileMaker then read about Solution development models