Table Design Question

[Lost_In_Tables]

I am creating a table, which includes a field titled
Problems. This field needs to handle multiple entries,
e.g., 1. Called vendor 01/02/03
2. Called vendor 01/03/03
3. Resolved issue with vendor 01/04/03

I know that the field can only hold one entry, however, is
there a way to accomplish the above task with a linked
table, document...etc.

Any help/suggestion would be appreciated.

Thanks,

Ed

 

[Jeff Boyce]

Ed

You've identified your solution (and avoided a major headache!). You really
don't want to include more than one "fact" in a field, mainly because of the
extra work it will take you to build routines to parse the separate facts.

If you are saying that you have Issues (Problems), and you have Actions
(related to Problems, e.g., calls, resolutions, etc.), you can use a
one-to-many relationship between the Problems table and a new Actions table.

I'll also point out that your first description:

e.g., 1. Called vendor 01/02/03
2. Called vendor 01/03/03
3. Resolved issue with vendor 01/04/03

included multiple Actions, AND included multiple facts within each Action.
I'd suggest you consider something like:

trelAction
ActionID
ProblemID (a foreign key field, pointing back to the Problem row for
which this action happened)
ActionDate (or Date/Time)
ActionDescription (what was done)

With this type of table structure, you can easily query to find which
Actions happened on which date(s), concerning which Problems.

For a user-interface, use a main form (based on tblProblem) with a sub-form
(based on trelAction).