If you were to implement an audit log system in Karbon, would you make it depend on transactions where every single field edit would go through the database transaction mechanism?
That’s an interesting idea, but I’m guessing that it would be too difficult to implement. I’m interested to see what you come up with.
We did create an audit log solution for a client that grabbed the entire record before and after the transaction, performed a diff of the two, and wrote the changes to a log immediately after the transaction was committed. This is not an audit log in the strictest sense, since the logging occurred outside of the transaction. True transactional audit logging in FileMaker is incredibly difficult to do outside of the Draco engine itself, so any solution will involve trade-offs.
(I don’t understand what you mean concerning the Draco engine…)
I may have missed something here, but I’ve found it very easy to implement the audit log transactionally given the model I use following the idea the my question here suggests.
Here’s the Update script that I use in my controller file that every field update throughout the system uses.
What may need to be pointed out here regarding my model is that I only use the global utility fields to edit values - the “real” data fields are rarely used in the UI.