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.
