Jason

In reference to Richard's question, it still sounds like you need a one-to-many relationship (not many-to-many).

A project has one or more tasks. Each task belongs to one project only. That's one(project)-to-many(tasks).

But I'm wondering if the terminology is getting in the way here? Does your Tasks table have one record per task per project? Or is it simply a list of all your available tasks? If the latter, I think I might see what you are getting at.

Maybe you mean this:

Projects –< Project_Tasks

 [one]      to       [many]

Where Project_Tasks are the tasks assigned to a particular project (so there is one record per task per project). Project_Tasks are chosen from Tasks, which is the list of all possible tasks.

You might then want to extend to this:

Projects –< Project_Tasks >– Tasks

So that each task relates to the many instances of that task (one for each project that requires it); by storing only the Tasks id in Project_Tasks, you can display the details of the task from the Tasks table via the relationship.

Maybe what you want is a display, in the Projects record, of all Tasks that have not yet been assigned to the project (by creating a record in Project_Tasks). Doing this is not trivial and I think you need to make sure you have the correct data (relationship graph) structure as well as a suitable means of creating Project_Tasks with the appropriate ids before trying to implement it.

Does this help clear the fog at all?

Steve


On 27 Jan 2011, at 10:34, Jason Bourque wrote:

> Yes, there are many review steps that have to happen in a project for quality control. And other tasks like prepare files for output that might be in the projects "dealer product photo request" and "send label files to printer". 
> 
> I used the many to many so the details of those tasks wouldn't have to be updated in more than one location.