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:
Mac (view)
/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.
Windows (view)
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:
DefaultStyle=”” attribute
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?
<UUID/> subnode
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
<TableOccurrenceReference/> 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.”
id=”x” attribute
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.
<TagList/> subnode
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:
<TagList>#_FMI_0 </TagList>
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!
Moving Forward in FileMaker 19
See more of our insights and resources on FileMaker 19 here. If you have any questions on how to leverage these new features in your solution, our FileMaker consultants are happy to help.
Thanks Mark some helpful stuff in there…
Wondering why you didn’t use Get ( RecordModificationCount ) as the autoenter calc on the modification count field??
Hi John, good to hear from you! Honestly, the function didn’t occur to me. I’m going to change the text of the article now, but let this comment stand as a grateful testament to your watchful eye 🙂
Mark
also pretty sure the tag line needs to be #_FMI_0 with a space after the zero
You’re right about this too. Even a single tag is followed by a space. I’ve made the edit now. Thank you!
We always add the following to our default fields:
zFoundCount – an explicitly-UNstored number calc whose formula is: Get ( FoundCount )
— This is extremely useful for checking related-record counts without loading those related records, and much more.
zSumAuto1 – a summary field of the “always has a 1 in it” field you mentioned above (which we name zAuto1). Also useful.
We also often add:
gCalcText – a global text field
cCalcResult_asText – an unstored calc whose formula is: Evaluate ( gCalcText )
— This pair of fields lets us create calculations on the fly in gCalcText during a script, and we can then sort records on cCalcResult_asText. As needed, we also make: cCalcResult_asTimestamp, cCalcResult_asDate, and/or cCalcResult_asNum. This technique is very useful when you use some kind of utility relationship (maybe Selector-Connector) and need to evaluate something from the context of the related record. You can put the calculation into that related table’s gCalcText and then read the CalcResult of the related record(s), perhaps even a List of that field from related records.
Hi Dan, thanks for sharing your go-to default fields. I like that technique for creating calculations on the fly!
Hello Dan,
How do you avoid the context problem with the zFoundCount field?
When I add this to my DefaultFields file and add a table it will show ‘from , = Get ( FoundCount ).
Hi, Mark!
I noticed when testing the “TagList” (back in 17), that the `#_FMI_0 ` means the field is NOT auto-magically shown on the layout created for a new table. But using the value: `#_FMI_1 ` would then make sure the field was always placed on the layout.
I think I tested other values and believe it’s a BOOLEAN, so 0 = not show and anything else = show.
Now if we could just get a default label and perhaps default allow entry…
Beverly
Thank you for sharing that information, Bev! So you’re saying the final number doesn’t anticipate a series of numerical codes, but instead is just a boolean. That makes sense since they didn’t make it ‘#_FMI_000 ‘ to ‘#_FMI_FFF ‘ (or something similar) to reserve plenty of possibilities.
Who knows, maybe they are planning ‘#_[TAG]_[bool] ‘ which would actually give more options if the tag letters don’t need to have semantic meaning.
I’m having trouble adding Summary fields, specifically a Count of the primary key and ListOf primary key. They simply don’t show up; has anyone cracked this nut?
e.g.
#_FMI_0
Peter
whoops, the comment engine munged my xml — ignore the example.
Hi Peter, good to hear from you! If you put your code between “pre” tags, it should stay intact…
Peter, have you succeeded in creating any default fields that reference other fields? For example, I’m thinking of a calculation that incorporates another default field in its expression. I’m wondering whether it’s even possible given the fact that such calculations (and all summary fields) include field references.
Hi Mark, I’ve been goofing around with fudging UUIDs but field references don’t seem to “take”. The best I can do with calculated fields is to embed functions within CDATA tags; field references appear to be a no-go (that I can see).
That makes sense to me in that we can’t predict the UUIDs for the fields being created. The alternative might be for the application to interpret the name of the field, or for some separate relative ID to be introduced, and both of those sound pretty sketchy as approaches under the hood.
It sounds like you’re treating expressions as literal text and then going back to edit them once the calculated field is created for a given table. Is that what you’re doing, or have I misunderstood you?
Mark, I don’t know if you’ve got default fields referencing other default fields working.
I’ve been doing this since 17 and it was working perfectly as long as the default fields referencing the other fields were later in the XML, but this has broken in 19.
I’m using a Custom Function that references other default fields and while it works in 17 and 18, the calculation’s formula is commented out in 19. The Custom Function is present in the file in 19 and correctly spelt too.
I’ve also tested a calculation field directly referencing the primary key and that is also commented out, so this is a definite change in 19.
What is interesting is that using ‘Save a copy as XML…’ in 19 comments out the formula with the Custom Function too but it doesn’t comment out the direct reference to the primary key.
Hi Damon, thanks for sharing your experience. One of the tricky things about FileMaker Pro 19 is that it’s not a monolithic version like all the ones that came before.
Probably I should change the name of this piece to “…Customizing Default Fields in FileMaker Pro 19.0”. It’s hard to know what will continue to work as new versions of the software are released throughout the year, especially things that Claris hasn’t necessarily committed to support. I’m pretty sure that this worked in the version that I tested, but that was a year ago now.
Imagine! We’ve reached the time of year when historically, a completely new version was released. Now, significant changes are coming our way every few months, and sometimes even more frequently than that. I don’t know about you, but it’s taking me some time to get used to this, especially in terms of supporting clients from one change to the next — though I do like not having to wait a year for exciting changes to come my way.
Thanks for the article, Mark! And yes I did not find any other way but creating calculations with the correct expressions in place but knowing they will be turned to comments once loaded into an actual table.
I thought that is not so bad, a price for a simple way to get standardised table definitions according to our standards; BUT…
did you find also that many of the nicely defined info and tags go away when you make a copy of the table and insert it again? Even in the same file?
The standard layout will show every field, identifiers for primary keys and alternate keys are lost :/
Still using the functionality,
Volker
Hi Volker, thank you for your comment. I’m going to try what you’re reporting here and see if it happens to me too. Cheers — Mark
Are these changes proving to be persistent across point updates?
Hi,
I’ve done all the steps, and I’ve done it before in FM16/17. But now somehow the file is just not loaded. I have two versions of FM (18 and 19) on my Mac (Catalina). So in /User/Shared/Filemaker I have two folders; Filemaker Pro (=v19) and Filemaker Pro Advanced (=v18). If I place the FMDefaultFields.xml directly in /Users/Shared/Filemaker nothing happens when creating a new table. The default fields are being set. If I place it in any of the subfolders nothing happens. Is there anything I do wrong, rights or locations?
Hi Dick, I’m not sure what issue you are running into here. On Mac for FileMaker Pro 19, the location for the FMDefaultFields.xml file should be the following:
Macintosh HD > Applications > FileMaker Pro > Contents > Resources > en.lproj (or the folder corresponding to your preferred language, such as “it.lproj”).
Please be sure you are replacing the copy of FMDefaultFields.xml that is located in that location. I rename rather than remove the original file so that I can revert back to it easily.
You might also try using the XML that I created for this blog post, since I know that it works — just double-checked it again.
Hope this helps!
Mark
Hi Mark,
Thank you. Now I renamed the Macintosh HD > Applications > FileMaker Pro > Contents > Resources > en.lproj > FMDefaultFields.xml to xFMDefaultFields.xml and placed my FMDefaultFields.xml in there and it works. So my file is working correctly. But I thought (reading step 12) it had to be placed in the folder /Users/Shared/Filemaker and there it was (not working though).
In step 12 you write “copy the file” instead of copy the file and rename what also set me off a bit. On the old filmmaker versions putting the new DefaultFields.xml in /Users/Shared/Filemaker folder was enough as I recall. So I’m still a bit confused. But very happy it does work.
Thank you,
Dick
Hi Dick, it is certainly better to place your new custom xml file in the custom location rather than change the original xml file directly, but it is a second option if you are having trouble. However, re-reading your original comment, I see that you might have the custom location slightly wrong, so let’s try that as well.
You wrote that you placed the file in: /Users/Shared/Filemaker/
But the correct location is: /Users/Shared/Filemaker/Shared/
Please see whether using this location works for you.
Cheers —
Mark
Mark:
This one saved me from pulling all my hair out!
Thank you,
Eric
Hey, good to hear from you, Eric! Glad to hear that this was helpful.
One observation is that you don’t have to quit and relaunch FMP with any tweaks to the XML file it seems that FMP does not cache this file. And referenced at the time you create a new table.
Thank you, Stephen — that’s good to know! I appreciate your taking the time to read this, and hope you’re doing well.
I know I’m late to the party, but I like to use stored calculations when I don’t want a user to be able to modify the data. Especially when managing systems where multiple developers have full access. It’s an added layer of data integrity that has allowed for tracking issues. Also, I’ve been doing a lot of experimenting with the “X to Data File” script steps and am pretty sure you can script the whole process from your demo file with those steps. Email me back and I’ll send you a copy.
Hi Rob, hope you’re doing well! Are you talking about setting up some stored calcs as default fields? Depending on the nature of the fields they can widen the table unnecessarily, but otherwise I agree, it can be a useful technique. I’m interested in your process for writing to a data file. Are you taking the existing default file, swapping out the relevant information, and then writing to a new file? That could be convenient for sure. However, it depends on how often you need to perform these tasks. I wouldn’t expect to change my default fields file very often. Of course, now that you’ve performed the work, other folks could certainly benefit from it as they set up their own. Cheers — Mark
Thanks! This article has been very helpful in setting up my Default fields, because this was something else that was aggravating.
Another related topic–>
Is there a setting somewhere in FM Pro that controls whether or not a new layout is created when I create a new table?
Here are my aggravations with it:
1) It creates a layout when I don’t necessarily need one yet.
2) It creates a layout using a Theme that I don’t normally use.
3) It creates the layout at the very end of my Manage Layouts view, which I either have to delete or move to another folder inside that view.
How to adjust all these things?
I know this isn’t exactly on-topic, but it is about customizing what happens within the FM Application.
Hi Dave, thanks for getting in touch! All that makes sense to me.
I’m not aware of any setting that lets you prevent a layout from being created, or decide where the layout is placed. However, I believe you can set up a Dynamic Template with a default theme of your choice.
Here is a Claris Community conversation about Dynamic Templates that might be helpful… https://community.claris.com/en/s/question/0D53w00005OjSJpCAN/changing-default-theme