Seeking your advice

[agtjazz]

On several of my posts, the responses given referred to Table Occurences... something that I know nothing about. I don't know how to create a table occurence or when/why I would need one. I have attached a screen shot of my relationships, and if you could provide any feedback, I would really really be grateful.

Thanks in advance for your time and honesty.

[agtjazz]

ok I figured out how to create a TO... so please disregard that question or subject

but if you could tell me when or why I would need a TO... that would greatly help me out.

Hope you are enjoying your day.

[LaRetta]

Hi there!

A table occurrence is EVERYTHING you see in your graph. Tables can not be accessed - only occurrences of them. We also sometimes call them TOs which can confuse people. :wink2:

[Lee Smith]

The actual words Table Occurrence show in the Edit box Specify Table when you are in the Relationship Dialog Box, and you double click on the Name of the Relationship (the Header), or when you add a Table using the "Table" Button at the bottom of the Box.

Le

[sbg2]

Maybe my post in this previous thread will help you....

http://fmforums.com/forum/showtopic.php?tid/172918/post/189790/#189790

[Fenton]

You've got Table Occurrences (TO for short). That's what the gray "boxes" are on your graph. They are a reference to a particular base table. The "relationships" are the lines between any 2 TOs, defined by double-clicking the little white boxes in the middle of the line.

A TO can have many lines, going in different directions, to other TOs. Hence it's not the same as a "relationship." You can only say exactly what record set will be produced by specifying an originating TO and the destination TO.* There can only be 1 line path (relationship)** between any 2 given TOs. Otherwise it would be a circular relationship, ambiguous, so FileMaker won't allow it.

*The TOs do not have to be adjacent however. A path through intermediate TOs is still a valid path.

** When you pass through intermediate TOs, what is the "relationship"? It is the logical result of all the intermediate ones. In 7/8 talking about "relationships" is really talking about the entire path. Hence you sometimes have to say, "This is the beginning TO and this is the end TO, and you'll have to look at the path on the graph." (Or use a TO naming convention that clearly specifies the entire path; but still, you often need to look at the graph.)

We're not in Kansas anymore (no offense to those in that state. I'm sure there are a few interesting places there -)

You've got a few relationships with < in them, between IDs. That seems wrong. Also, you would not link an Employee directly to a Job, unless there's only 1 employee per job. But it's hard to say much about someone else's structure when one has little idea what the concepts are. "Job" especially is an ambiguous (my word for the day apparently) term.

One other thing. Please collapse your TOs on the graph to show only the keys involved. It's Control (or Cmd) T. Select All first, if relevant. It takes up so much less space, and is easier to arrange.

[agtjazz]

So if I want a person to have job information and contracts... (one person can have more than 1 job and contract and also- and no- there's not only 1 employee per job... there could be 25 people with the same job, but different salaries or something)--- what would I have to change or implement?

Thanks in advance

[Fenton]

You would need a "join" table between People and Job. It would have the People ID and the Job ID, tied to the relevant primary ID in the parent table. And any other data that belongs that that particular combo, such as the date(s) involved. And possibly its own serial ID -]

When adding a Person to a Job you're actually only adding a record in the join table. This can be done from either side, choosing the ID of the one you don't have, while allowing the ID of the current parent to be auto-entered by a portal with "Allow creation of related records."

[agtjazz]

I am wondering if I still need a join table if Job holds job assignments-

please see this post in another topic

http://fmforums.com/forum/showpost.php?post/203599/

the job table records are unique for each person... not standardized.

Your help and patience are appreciated more than you realize. I am sooo amazed at how helpful this forum is without rude and demeaning comments to people like me- complete newbies but need to learn fast.

Edited April 28, 2006 by Guest

[Fenton]

The term "job" is so vague. A "job" may last 15 min., it may last 10 months, and have hundreds of "tasks" within it, or even a hierarchy. "Job Assingment" is a better term, because it signifies 1 particular "job" (whatever it may be) assigned to 1 particular person, at 1 particular date-time.

Since the Job Assignment (JA) is NOT the "job" itself; UNLESS there's only 1 person assigned to it, and assigned only once, then you would need a separate Job table, and JA would be the join table.

We don't really what the real world objects and situations you're dealing with are, so we can't really say.

Also, please don't keep both of the threads going. Either one or the other. It is somewhat annoying for us to have to read both to see where the discussion is going. So far it hasn't really mattered. But specific discussions should be kept to one thread. They can be merged, but it's up to you.

We are not often rude, and seldom demeaning, but we can be blunt; we like to think of it as "tough love" -|