1 of 1 people found this helpful
Not sure it there's a white paper on this.
It basically comes down to this:
If the layout is associated with a table, at the moment the layout loads the client will ask the server for the Master Record Table of that particular table.
This master records table contains record id's of all the records.
Those are internal to FileMaker and have nothing to do with any primary keys you defined yourself.
You can find this out with Get ( RecordID ) function.
Each record ID is 1 Bit in size ( at least what was said in the video ).
Data is sent in chunks ( around 1500 bytes per chunk ) which makes up for one round trip.
The more records in the table the more data ( record id's ) need to be downloaded from the server.
Depending on the network speed and latency ( remember round trips, packets need to go back and forth ) it takes time to complete the process.
A round trip could be: Server Sends Data, client accepts and sends Acknowledgment back to server.
The latter could be a small bite size but if latency is high, the server will wait longer until it hears back from client, the client will wait longer for new data to come in.
I'll omit the fact that packet acknowledgment can be bundled up which helps a bit...
Therefore it is in general better on startup to go to a layout which has few records or none at all.
Eventually one might want to go to that layout and it will need to be downloaded, but it's more about the perceived "Solution Startup" speed that clients might find annoying.
Once they're in you can make further decisions on that to do next.
Good evening Thomas,
I hope your day is going well. Thanks so much for your detailed reply! So, in a production solution the ideal situation, from a performance perspective, would be to create a table with no fields and load a layout based on that table first? Thanks and have a great evening!
The issue is more about perception of speed, and doing things only when needed.
If the solution has a little-used table of thousands of records, don't touch any layouts associated with this table until it's needed.
I've seen a couple of solutions that display a splash screen, then change to each table and show all records, then go to the home screen. The rationale for this may have been that there were saved found sets in some tables, and this process clears them.
Knowing that changing to a layout causes the master record list to be pulled down, it can be seen that the process of going to each table and showing all records is a resource-intensive action and on a slow network will be painful.
A better way would be to keep track of which layouts have been visited and show all records only when necessary.
The best method is to set up a script that does this process when the file is closed (not opened) if and only if the file is opened locally and not hosted in FMS. That's because the found sets are only saved when the file isn't hosted.