...Or at least I think so. I have four related tables: Services, Labor, Difficulty and Service Items. Services is the main table and is a list of possible services a vendor can offer. Difficulty is a related table that contains related records that help populate a dynamic value list.

Each service can have it's own method of defining levels of difficulty. It could be a Simple Medium Complex set or perhaps intensive, non-intensive. Each difficulty schema is given a name identifier which becomes the match field (e.g. if "S/Med/Cpx" is selected in the Services Difficulty Scheme field, the value list in Service Items will be populated by three values, Simple, Medium and Complex.

This part works. The problem becomes when I try to add a portal interface to the Services table which will allow creation of Labor records. Labor records define how long each service at each difficulty level will take. So the Labor table must create (using our s/med/cpx scheme example) three related records, one for each level, and allow the user to add a value for the amount of time each takes. However, when I build a portal, with the Difficulty Levels (with the value list) and Time Taken fields in the Services table, the value list will only populate when a value is added to the Time Taken field.

I have attached the TOG that the problem occurs in.

I think there may be a better relationship method I am missing. I could simplify so that the difficulty scheme is built each time (merging the Difficulty and Labor tables), but I liked having "presets" that could be selected for each service and that could be added to by certain users in a reasonably simple interface.

I hope I have explained this well. Thanks in advance for all replies.

Questions:

Service Items are attributes of Services? Therefore you have many=many?

Second, Difficulty and Labor are direct attributes of Services but not direct attributes of Service Items? Again, you would have another many=many relationship?