Good day to you all
Is there any native functions to do extensive audit trail logs in file maker pro.
Thank you in advance!
Dont know about native functions.
But i solved it by collecting "old value" on object enter and if changed, typing to log on object exit.
This is the tool I mostly use for Filemaker Auditing - it's super simple to implement, and is built upon a custom function:
NightWing Enterprises - UltraLog v2.x Audit Logging Demo for FileMaker Pro
Tick to NightWing. A very useful tool, Kuda, and just what you are looking for by the sound of it.
+1 to ultra log by Nightwing
also gotta mention fmDataGuard from LinearBlue
If you want more than audit thats your product
I have tried that, but not good enough for the solution. what happens when i create or delete a record. Who logged in or viewed a record.
LinearBlue product seems good. Do they have a trial period
UltraLog handles creating a record just fine. Deleting a record would require scripting the deletion process to prevent someone from using the native functions. You’d also probably want to have an archive table to move the record to before it was deleted from the live table. Logging in is easy enough with a Sessions table.
Who viewed a record? How would you trigger such a function? Every time someone scrolls to a record, record an entry in a table? What about List view or Table view? How do you determine if someone viewed a record without putting the focus there? What about a related record through a portal? Does that count as “viewed”?
About the only way this would work is if you didn’t allow List or Table views, or portals, and you scripted the movement between records.
There is no off-the-shelf product that provides all this functionality. Not that I’m aware of, anyway.
What is the application here that demands this level of auditing? Are we sure FileMaker is the right tool?
Adding to Mike's, especially "You’d also probably want to have an archive table to move the record to before it was deleted from the live table."—
Bear in mind that UltraLog works as a field within the same table, so if a record is deleted the log data goes too. For that reason I would disallow record deletion, but rather manage this via a script which captures essential record data and stores it in a separate archive table, just in case. This scripted "delete" process also gives you the capacity to capture details of who did the deleting and when, etc.
If you have that level of auditing required you might think about flagging a record as "deleted" and just not showing it to the user. Do not in fact delete the record.
Sounds like you should be using FMS and the server provides access logs.
As Mike M said tracking views of a record is definitely chasing your tail.
Access logs are good, but they only tell you the file was accessed, not each record.
Check out: Using ExecuteSQL() calls in FileMaker - Soliant Consulting
It's a devcon session I did a few years ago to build a native audit log that is fairly advanced and uses nothing but native functions. Many of them functions that we otherwise overlook.
Wim you stink... This would have been work the price of DEVCON admission alone.
Retrieving data ...