Zero to Awesome - Using a History table: Part 2

Navigation

FileMaker Deals

Video Browser

Zero To Awesome - Using A History Table: Part 2

Posted by: Editor / Monday, September 8, 2008 – 4:34pm

by Matt Petrowsky

minutes

Article options

After a number of people emailed me, I decided to go into a bit more depth about using a History table. Keep in mind however, this article isn't just about providing the great feature of showing a user their own history of actions against records - it's about editing data through a utility table - in order to gain useful functionality.

Any time you wish to edit data within a FileMaker table, you need only realize that don't have to edit that data directly on a layout which is tied directly to that table. You can edit data from a field on ANY layout, provided you have a valid linking relationship to that information.

If you remember this one little tip, then working with a separation model will become a lot easier to mentally grasp when attempting it!

Details: Released - 9/8/2008 / Size - 26.25 MB / Length - 19 min

About author

Matt Petrowsky is the Senior Editor for ISO FileMaker Magazine. Matt has been involved with FileMaker Pro since the early '90s. Having authored many articles, a popular book, spoken at conferences and seminars, as well as provided private training, Matt is continuously updating his knowledge and skill about the powerful FileMaker platform. You can contact Matt by sending email to editor@filemakermagazine.com.

Filed under: videos | Subscribers Only

Amazon.com Widgets

History table structure still confusing

morley said this on Sunday, September 14, 2008 - 5:01pm.

I'm very interested in adopting your History table structure into my solutions and have just watched your second video on the subject. I'm experiencing some points of confusion.

1. From the video it's fairly obvious the solution's current data will be stored in tables just as it's always was, but that record creation and record editing will be performed in the History table. What doesn't seem to have been covered is the integrity of the match between the History table and the People table. I'm sure I'm missing something and here's why.

When the user chooses to edit what they assume is a People record what actually happens is that a History table record is duplicated. Once the user exits their editing process, how is the data moved to overwrite the existing record in People?

2. I'm confused by the user of two tables both called Users. Calling two tables (in two separate files) by the same name is ill advised, leads to confusion. But that's not the confusion I'm talking about. The Data Users file has one record per user of the solution for storing access permissions, last windows open, window location, etc. That's obvious.

But I'm as clear as mud about why the two Users tables can't be combined into one, one record per user. The video dances right past the necessity for two tables, presumably one record each per user. What exactly is it about the User table fields of that "local" UI file (wherever that file is located) that couldn't be place in the server's Data file? What am I missing?

Morley Chalmers
--
Do not worry if you have built your castles in the air. They are where they should be. Now put the foundations under them. -- Henry David Thoreau

» login or register to post comments | email this page