Back from Rome, I remember a few tips for performance and best practice to think about in Claris FileMaker, so let's write them down, before I forget them:

Don't show all records

For best performance, don't show all records to the user. Remove the menu command for this via custom menus. And change the toolbar to not have the command.

Make sure the user never sees all records. Always do a find for them to reduce the number of records shown for performance. Like do a search to show records from the current week or the entries the current user has to work on.

Why? Because the user almost never needs to see all records and scroll down to find theirs. While all records are showing, the FileMaker server sends notifications in the network to update the list whenever one of the records shows. If you show 1000s of records, there are a lot of such notifications coming, which may cause a refresh.

To change the toolbar on macOS, please check our toolbar functions.

Split tables for smaller records

When designing your data model, please consider that FileMaker loads records as a whole. If you show only a few fields from a table with 20 fields, all the data is transferred (except containers). 

If you store big block of texts and you don't need them always, please consider to put them in a different table.

Like the logs from CURL for a transfer or a big JSON text.

Don't show delete record

Again, use custom menus to remove it or change it to do what is appropriate for the current situation. The user should not delete records directly, but you control it via script. They may delete orders, inventory entries or emails, but the user never deletes records. You may have a script to set a field to mark the entry deleted and your current list of viewing items performs a find to only find records where the deleted flag is off. This again means the user can't see all records.

To change the text of the FileMaker delete dialog, please check our DialogModifications functions.

Do your PSOS in a separate file for server

In a solution with multiple files, group the server scripts in a separate file and with their own layouts. This avoids conflicts with layouts for the user. Better performance as the layouts for server scripts don't have fancy user interface, but only the required fields. So you skip loading in portals and doing joins. And less problems as a change you make for the user doesn't break the PSOS script.

Same applies for Data API things. Have the scripts separated with their layouts to work on.

Learn more on the next conference.