Getting tables to relate

[Hack]

Hi

I am having trouble with couple of table relationships

I have attached FHP file and screen shot....

I am have trouble with linking "project sheet" table to "job instruction" table

I can link through script (i.e navigation linking) from "projects sheet" and place in job instruction through pull down menus...

What I waiting to do is set up some script up for a nav buttons so I can link from "project sheet" table to "job instruction"

in addition: (screen a little different to FMP file attached

I also tired adding a job instruction ID in all the tables I wont to related as you can see in the screen dump but this also not working?

if any one could help it would be great

Cheers

Hacky :

print_specs_Clone-v2.fp7.zip

print_specs_Clone-v2.fp7.zip

Edited March 2, 2006 by Guest
better to understand

[T-Square]

Hacky:

Your structure is really complicated, and you are making heavy use of non-key relationships, which confuses things substantially. In your relationships graph, I see at least Clients, Project Sheet [perhaps better named as Projects], Job Instructions [perhaps better named as Tasks], and job_ref [i don't understand what this is]. I'll use my table names below; correct me if my assumptions are wrong.

For starters, I would recommend using a single unique ID field in each table. Then, use these single fields to form your relationships. That will begin to clarify things.

I believe the structure should be a hierarchy: Clients->Projects->Tasks. Clients have Projects. Projects have Tasks. If I am right, then read on.

To implement the sentence "Clients have Projects", create the relationship: Clients::ClientID<->Projects::ClientID

To implement the sentence "Projects have Tasks", create the relationship: Projects::ProjectID<->Tasks::ProjectID

For example, I'll assume that you have a link between Clients and Projects. Each Client has a single Client_ID that's a unique number, hidden from your users, and necessary only for uniquity (). A Projects entry layout then could have a Client_ID field that used a value list to select the client for that Project, or you could script it. Tasks appear to be associated with a particular Project, so your Tasks table would have a single Project_ID field which would be linked to the Projects table. Your Tasks table doesn't need a Company (that's associated with the Client, which is linked to the Project) or ClientID (that's derived from the Projects table). Your Projects table doesn't need JobTitle (that's in Tasks) or Company (that's derived from the Clients).

Does this point you forward?

David