Daniel Wood suggested a rather interesting idea on how to make HyperList and MasterDetail even faster.  In short he suggested using FileMaker’s built in record ID instead of the primary key.  Its really rather brilliant and turns out to work quite well.  You can read his full explanation over at Modular FileMaker. Its in the comments for HyperList.

I thought I would give the idea a try with a very large record set to see if it speed things up.  Well it did.  Here is the video to prove it. Enjoy

3 responses to “MasterDetail and Record ID”

  1. Bruce Robertson says:

    I suspect the faster performance for the unstored native record ID calc is a mistake. It certainly isn’t the result I get.

    My tests show 2X faster performance for using ListOf on the stored RecordID calc.

    On a LAN I’m getting 135,000 ID/second for the stored native record ID calc.
    I get half that for ListOf unstored record ID calc.
    I get 56,000 ID/second for a ListOf on a stored UUID field.
    I get 135,000 ID/second for ListOf on a stored integer ID field.

  2. Todd Geist says:

    Hi Bruce,

    First this was with FileMaker 12 not 13. It sounds like you are on 13. So the results maybe different. I know for a fact that FMI engineering was looking at the bug behind the need for HyperList. Maybe the snuck in the fix. I’ll have to check.

    I don’t think this is a mistake in FileMaker 12. Both Daniel Wood and I independently verified the results. The un-storred ID is faster over the WAN.

    In 13, ListOf doesn’t impress me much. Having to add a field to the DB just to get a 2x boost that only matters with large record sets seems like a shallow victory. I would only use it in cases of extreme need. HyperList is much more portable.


Leave a Reply