Developers > BH&A AuditLog System
Welcome to Transactional BH&A's AuditLog System™ 1.0
FileMaker's latest product evolutions have allowed developers to implement their solutions in ever demanding environments, where data integrity is simply not questionable. In such environments, being able to log and retrieve data changes is an almost obvious "must have".
BH&A's AuditLog System™ allows you to properly track every single data modification in your FileMaker databases. Over the years, you might have developed your own techniques to accomplish this, with unfortunately, a number of probable, major drawbacks:
- the modification log is stored on the record itself: delete the record, lose the log;
- no trace kept of the first value given to a field during imports, often the most important to retrieve;
- not transactional: modifications are logged before the user even confirms them: what if he/she reverts?
- depending on complex plug-ins that might not be supported forever or sometimes difficult to use;
- strong dependance on field names: change a name, ruin the system;
- difficult to set up.
With BH&A's AuditLog System™, you get an almost perfect audit log. You can choose to log changes on all tables and fields or select the fields to audit, by simply placing them on a layout!
Whether the modification results from an import, a user action, a script, a lookup, auto-enter... find it in your audit log, in a separate file.
(please note this demo works on a single file. it would be safer to store the log on an independent file)
Finally, BH&A's AuditLog System™ relies on an almost native FileMaker technique. All it requires is a free script trigger plug-in such as myFMbutler DoScript™ or zippScript™ that have become essential to any professional solution.
Features
- automatically logs modifications on all standard fields (calculations, globals and summary fields are of course not logged);
- alternatively, you may select the fields to be audited by simply placing them on a layout;
- link log records with a transaction number. This makes FileMaker transactional in the sense that every modification is asscociated to a transaction. Roll-back becomes childplay !;
- turn audit log on and off by simply setting a variable;
- set up a feed back message so that the user knows when the log is being written. Customize your alert string and set up a threshold, so the alert is displayed only if more than n (the value you defined) records were modified in a transaction (in this demo, the alert is displayed if more than 20 records are modified. It is visible during the import script).
- the log is recorded in real time. A server compatible script updates the detailed log offline. This detailed log is easier to read and faster to search.
Restrictions
- not compatible with web publishing, but easily adaptable if you're in control of the navigation (hide status area and script layout/record changes)
- will not work if a script modifies data, commits, then halts (in this order)
- will not work during an import that does not perform auto-enter options
- if a subscript is performed in Full Access, and modifies data without committing, data changes will be logged properly, but privilege set name will be erroneous (user’s privilege set name will be logged instead of [Full Access]). Adding a commit script step in the subscript solves the problem.
- well... that’s all !