This is inspired by the discussion here: https://the.fmsoup.org/t/most-efficient-way-to-navigate-to-the-new-layout/
I have a "Log" table used for general auditing and debugging, and a Log() script which takes parameters (severity, message..) and creates a record in the log table. This is a general-purpose script, and as such it has to work from any context (window, layout, mode etc.)
Right now, the script
- keeps track of which window is frontmost
- parses the script parameters to extract severity, message...
- creates a new window (or shows the Log window if it's already open)
- creates the new record
- commits it
- goes back to the original window.
This works, but is pretty slow, and does occasionally have side effects such as changing window order, etc.
Is there a better way?
- instead of creating a new document window, create a new Card window (since that's apparently lower cost and doesn't affect the current layout)
- FileMaker's ExecuteSQL would be great, but it doesn't work, since it's read only (SELECT, not INSERT)
- Using a plugin such as MBS which can do a SQL insert: Monkeybread Software - MBS FileMaker Plugin: FM.InsertRecord
- using the "Magic Key" technique - unfortunately, this requres the current TO to have a relationship with the Log() table, so it's not a good general purpose solution.
Here's a couple of new ideas I had:
Write a Log() script that uses Perform Script On Server. Pass it a JSON string with the data, and the actual record creation happens server-side.
- Since the record creation is taking place in an entirely separate process, absolutely zero Window or Layout changes would be required.
- if the timing of record creation is not critical, you can set Wait for completion OFF
- I'm guessing the overhead for this is gigantic
- if Wait for Completion is OFF, you could have issues with record creation happening out of order
Use Data API
Use the FileMaker Data API, triggered by the InsetFromURL script step.
- may be lighter-weight than using PSoS ?
- requires special Data API setup
- only works when files are served from FileMaker Server (e.g. wouldn't work when running in FileMaker Pro locally)
Any other clever ideas?