Designing an FM Db to Track History Info

[Chappy.Cole]

I have occasionally wanted to track the history of some bit of data. For example, right now I want to create a db which contains the following fields:

-> Customer Name

-> Customer Phone

-> Customer Issue

-> Current Issue Status

-> Current Issue Status Date

-> Current Issue Status Description

-> Issue Status *

-> Issue Status Date *

-> Issue Status Description *

in which, the last 3 fields with the '*'s, can repeat endlessly. In other words, as time goes on, for any customer issue, the status will change some unknown number of times. I would like to put together a db that handles this in such a way that it is easy to design a layout that allows a user to "walk" through the history of the issue.

My one thought on the matter is to do the following:

> Make 2 db's: 1) Customer Issue Db; 2) Issue Status Items

> In the 1st db, define a field as an automatically serialized number which is the key field for relating this db to the 2nd db.

> Then use relationships with "allow creation of related records" and portals to allow multiple entries in the 2nd db to share the serial number from the 1st db.

Will my idea work? Any other thoughts?

[Tim W]

Hi,

Welcome to the forum.

That is how I would approach a solution, also. Will there be any reports? Or searching for similar issues (IssueClass, IssueGroup, etc)? Could an issue log by equipment description or machine be of use?

Just some ideas,

Tim

[Chappy.Cole]

Thanks for the welcome!

Thanks for your reply also. I'm already glad I joined this forum community.

It's possible that I might need some of the other tracking fields that you mentioned, but for now, I just want the basic feature of customer info, issue description, current status and history.

Thanks for the ideas and help.

Chappy Cole