When you create a new table in FileMaker Pro 19, it starts out with a set of commonly-used default fields. Perhaps these fields aren’t exactly the ones you’d like to start out with — or maybe you don’t want to have any at all. This article will introduce you to how to configure your own set of default fields.
If you’ve configured default fields in previous versions of FileMaker Pro, you may — with a tweak or two — be able to copy just the nodes from the old file to the new one. The enclosing nodes have changed, so don’t copy them. Beyond that, you may want to skim this article to get a sense of what’s different in FileMaker Pro 19.
Just about everything in your FileMaker file is stored as Extensible Markup Language (XML), and the default field settings are no exception. You can find these settings in a file called FMDefaultFields.xml at the following locations:
/Applications/FileMaker Pro 19/FileMaker Pro 19/Contents/Resources/en.lproj*/FMDefaultFields.xml
* This is the actual application package. To open it, right-click on it and then choose “Show package contents”
** You will see a series of localized folders such as “en.lproj” which is English, “de.lproj” which is German, and so on. Each of these folders contains its own FMDefaultFields.xml file. Choose whichever one matches your language preference in FileMaker Pro.
C:/Program Files/FileMaker/FileMaker Pro 19/Extensions/English*/FMDefaultFields.xml
* You will see a series of localized directories such as English, Spanish, and Japanese. Each of these folders contains its own FMDefaultFields.xml file. Choose whichever one matches your language preference in FileMaker Pro.
Once you have located the default file, copy it to your desktop or another location where you can edit it. Open it up in a text editor, and you will see XML with the following structure:
<?xml version="1.0" encoding="UTF-8"?> <FMDefaultFields> <ObjectList> <Field id="1"...> [subnodes describing field options] </Field> <Field id="2"...> [subnodes describing field options] </Field> ... <Field id="5"...> [subnodes describing field options] </Field> </ObjectList> </FMDefaultFields>
The customization process simply involves making changes to the nodes. You can modify them, remove them, or add new ones with appropriate XML representations of the fields you’d like to have created automatically. Of course, the tricky part is getting the XML correct.
One way to figure that out is to create the fields in a new file, export an XML representation of that file, and analyze the portion of the XML representing the fields you created.
Get the Sample Files
Download the sample files to follow along with with my instructions.
- In FileMaker Pro 19, select File > Create New to start creating a new file. A FileMaker Pro dialog window appears, showing various file options.
- Select the Blank option and click the Create button. A file dialog appears.
- Name your file DefaultFieldsTemplate.fmp12 and click the Save button. The file is created. If you have enabled the preference Use Manage Database dialog to create files, the Manage Database dialog appears. If you have not, select File > Manage > Database… to open this dialog.
- Modify the fields in this table to meet your requirements, changing, deleting, and adding fields as you choose. The resulting table should include only those fields that you want as your defaults.
For example, I like my primary key to start with “__pk_TableName” so that’s what I call the field (substituting the actual table name later). Now that the FileMaker Migration Tool helps to coordinate serial numbers during data migrations, I find that I prefer serial numbers to UUIDs, so I make that auto-enter change too.
I’ve found that requiring these fields to have a value has gotten me into hot water, so I also remove that requirement from all of them.
Also, while I rely heavily on the standard metadata fields such as Creation Timestamp, CreatedBy, ModificationTimestamp, and ModifiedBy, I make some tweaks to them:
I prepend a “z_” to them to group them together as utility fields. And because I have a thing for parallel grammar (I believe that it reduces cognitive load), I call the timestamp fields “z_CreatedOn” and “z_ModifiedOn” to match “z_CreatedBy” and “z_ModifiedBy”. I also prefer to record the host timestamp rather than the local timestamp of the user, as this helps keep data consistent when users are in multiple time zones.
To give an example of a calculation, I’m exposing FileMaker’s internal record ID, though normally I’d set it up as an auto-enter field. Can you think of any standard utility fields which make more sense to set up as calculations than as auto-enter fields? I’d love to hear about them in the comments.
I also add a field that always contains the value 1. It’s useful in relationships and summary counts.
And finally, I include an auto-enter number field that records the number of times the record has been modified, giving me a sense of the volume of activity that each record has experienced.
- Once your field changes are finished, click Save to close the Manage Database window.Great! But how do you figure out the XML for the changes that you’ve made? Well, some changes – like the field names – are pretty easy to make directly to the default XML. But I recommend you compare an actual file to the default XML.
- Select Tools > Save a Copy as XML. A file dialog appears.
- Name the file FieldExport.xml and click Save.
- Open the FieldExport file (view). It contains an XML representation of your DefaultFieldsTemplate database file. On Mac OS, I use BBEdit as my text editor, but there are lots of good XML editing applications available. Notepad++ works great for Windows OS users.
- Remove the surrounding XML that isn’t relevant to your default fields: only keep the portion in the <FieldForTables/> node (view).
- I like to add a couple of lines of whitespace between the nodes. This makes it much easier for me to read the XML.
At this point, the nodes of FieldExport.xml should be pretty similar to FMDefaultFields.xml, but you can’t copy from one file to the other without making some changes.
- Figure out what needs to be changed and change it (view). This can be a process of trial and error, but here are some guidelines:
Remove the DefaultStyle attribute from the Field node (DefaultStyle = “”). I haven’t been able to figure out what this is for…maybe some nifty future feature?
Remove this subnode completely. It uniquely identifies the field within the file, so it doesn’t make sense to expect it to be duplicated from one instance of the field to the next.subnode
Remove this subnode completely. This is important. It essentially tells FileMaker Pro that you are trying to reference a specific table occurrence with a specific UUID – and that’s not going to exist in any file except the one you got it from. Even in that file, I’ve found that it seems to cause the calculation to have a context of “unknown.”
Your set of default fields should have serial IDs starting from 1. If you are adding a new field to the list of default fields – or removing existing ones — make sure that there are no gaps in the IDs.
I have a lot to say about this one. If you look at the original set of default fields, the primary key field has this:
<TagList primary="True">#_FMI_0 </TagList>
where the “primary” attribute flags this field as the primary key.
The other four default fields have this:
The “#_FMI_0 ” tag indicates that these are utility fields, which aren’t added to the default layout automatically when a new table is created.
When I perform the Save a Copy as XML command on my fresh new file – where I’ve made no changes to the default fields of the default table – the primary key field shows up with a new tag included:
<TagList primary="True">#^FMI* #_FMI_0 </TagList>
I’m going to guess that the tag “#^FMI* ” is a new way of indicating a primary key (with the “primary” attribute included for backward compatibility). But that’s just a guess… I don’t know why it’s included on an actual instance of the field but not in the default fields file. It’s a little troubling to me that they are tagged differently. It certainly would be great to see a dictionary of the most common tags.
I’ve tried including the extra tag and not including it, and I don’t see a problem either way when a new table is created. Superstitiously, I’m going to recommend that you stick to including only utility fields in your default fields file and that you tag all of them only with “#_FMI_0 ” – adding it when it’s not there. But if you can shed more light on this, please leave a comment – I’d like to learn more!
- Copy the FMDefaultFields.xml file from its default location described at the beginning of this article to the following custom location:
- Open the file in the custom location.
- Copy all the <Field/> nodes from your FieldExport.xml and paste them over all the <Field/> nodes in the copy of your FMDefaultFields.xml file. Your selection should start with the first <Field…> tag and end with the last <Field/> tag.
- Save your customized FMDefaultFields.xml file. That’s it – you do not have to restart FileMaker Pro 19.
- Switch to your DefaultFieldsTemplate.fmp12 file in FileMaker Pro 19 and try creating a new table.
- Are your custom default fields created automatically with the settings you specified? If not, review your FMDefaultFields.xml file for syntax errors. And if you discover something that I’ve missed, please let me know in a comment.
One unexpected behavior that I’ve noticed is that calculations (both regular and auto-enter) that reference other fields first appear to be commented out. But if I commit the table and then re-open the Manage Databases… window, the issue is magically resolved. Since I’m looking at a preview copy, this may be a bug that will be resolved by launch.
File Differences in FileMaker 19
In summary, although the filename has changed along with a few of the enclosing nodes, there isn’t a huge difference in the overall structure of the new FMDefaultFields.xml file. Likewise, although FileMaker Pro 19 adds some new nodes and attributes to how it represents fields, these differences are easy to accommodate as well.
So put your best field forward when starting a new file — and have some fun doing it!