Zero to Awesome - History Tracking Revisit
Because I've added history features to the My Invoicer solution, I decided to add one more video to the mix about using a History table. The concept behind the whole approach is to simply use a dedicated table which will track pretty much everything a user does to any data in the database - provided you account for such actions. This isn't exactly audit logging. It's another dimensions to knowing who is doing what in the database.
Using a History table is an extension to using a Sessions table, wherein with sessions you're tracking what a user does between the times they login and logout. Add audit logging to using a history table, and you have an extremely robust tracking and logging system.
There are many ways to approach data history and tracking. In my solution, I've opted to use the History table as the primary place where users interact with data. With the addition of Script Triggers in FileMaker 10, it's certainly possible to achieve history tracking using triggers on events such as OnLayoutLoad. This means you don't have to edit data through a relationship, such as is done in the My Invoicer file. However, there may be some advantages to taking this approach. Ultimately, no matter how you accomplish it technically, the goal is to maintain the history of what is done to the data in the database. A history table helps you accomplish this.
Comments
Current record
Hi,
How do I assure that users only see current records. Lets say I modify a records several time. I want to look up a phone number. I don't want the users to see old version, unless they specifically need to.
There is no easy way to do this from the history table unless I keep them in a found set. But how do I create that found set. Ie, how do I create the Current version of a records. Using a relation ship to get the latest version is very slow for large amounts of records.
Kaostika