contact table

[zab]

HI people

I'm looking for the very best and simple way to create my contact table and divide it with TO. I read in the FM bible that I can create many TO for every type of contact but I'm just not sure if I create many different ID for every type of contact or do I use a "type' field a sort them?

please can someone tell me the right way.

Oce I get that right I'm sure I will use it for so many other things.

Here is what i have:

contact table:

-desk employees,

-mill employees,

-(desk and mill employee have the same type of employee id (1 to 300)

-clients (related to one project only),

-sellers (a seller can also be a desk employee occasionaly)

-business partners (Is it better to create a table for this one and bring the contact employee in a portal?)

-partner's contact( employee)

SO do I sort them with script only? or not?

Tank you so much

Isabelle

[Ocean West]

Try starting with this thread - this may be the most practical approach

http://www.fmforums.com/forum/showtopic.php?tid/198682/fromactivity/favorites/

[zab]

Thank you for the link, it's very interesting but now I'm lost in theories. I need to know more about Supertype, subtype etc. I think I get the general idea (if not the right word) of it but what I really need is to know the simplest way to seperate the types here. One simple example that maybe have a simple answer.

I have a table with jobs to be done, description etc.... I have a type field with list choices: development, active, validation, closed.

If I want to create an archive with only the closed job in it and I want my main table to show everything else except the finished jobs. What is the best way to accomplish this? I have some ideas how I can do this, but I'm not sure it's the right way...

Thank you again

Isabelle

[comment]

The best way, IMHO, would be to keep all jobs in the same table, and perform a find for the type/s you need. This can now be done automatically with script triggers, so you can have "filtered layouts".

The supertype/subtype model is best suited to situations where each subtype has specific fields, in addition to the fields common to the supertype.

[zab]

Yes it was my first idea. But I can't use script trigger because, even if I have fun with FM10 on my mac, the users are restricted to FM 9 on a windows 2000 server and xpon their computers...

I still need to know how those TO works for my contact list.

[comment]

I can't use script trigger

You can still use scripted navigation, and restrict users ability to perform finds that would exceed the current "scope".

still need to know how those TO works for my contact list.

I may be missing something, but I don't see how having a TO for each type can help. You create TO's to facilitate relationships, not to reflect an internal classification (the TO is not "aware" of it anyway). In some situations, you may end up with a graph that has a TO for each type - but that is more of a coincidence then a planned result.

[zab]

Really. I had the feeling I could use TO's to sort my contact in some way. Because I don'T want to see them all together in my contact list. I mostly have the same informations about them all but I have different utility for them in my database. For example. I need my desk people to track their job (customer service and such) and I use a portal for that. While my mill employee names are used in the compilation of production time. don't need the mill employees to have a portal on their layout nor their addresses (maybe soe day for the human relation I will need more) for now, I want to keep it simple for them.

Right now all my contacts have different tables (clients, desk employee, mill employee, business). It work fine but I have the feeling it's not the right way to do this, I will develop this database for some time and I'd rather correct my beginners mistake now rather than later.

So what is the best solution. Put them all peoples in the same table, businesses on another and sort them in TO with scripts. I need the TO because they all are related to very different tasks and tables anyway.

I tried scrip trigger and it did not work on FM9... maybe some of it does. But I won't put much energy on it if I can't use it. It's sad but our servers are not ready for FM10... really bad because I love it.

Thank you

[zab]

Where can I find a clear explanation of the supertype and subtype model?

Thank you

[comment]

If you are using portals to view data, then yes - you can force the portals to show only certain types of related data. But this is done by the relationship, not by the TO. The same TO could feed a completely different set of data to another portal, through a different relationship. And of course, a layout based on the said TO is not restricted in ANY way: if you select Show All Records, that's exactly what will happen.

Another point which you may consider is: do you actually need to have all your contacts in the same table? Are there things you need to do that involve all contacts at once (e.g. send a birthday greeting)?

Where can I find a clear explanation of the supertype and subtype model?

Try Google? Here's one that looks interesting:

http://technet.microsoft.com/en-us/library/cc505839.aspx

[zab]

The main reason why I want my contacts all in the same table is because one person have more than one job: a desk worker and a seller and a buyer. I need to interact with those contacts on different tables for different tasks. I tried a few things.

I put all my contacts in the same table.

Made a "type" check box for all different jobs that one contact can do. Made an contact id and jobID. (exactly as shown in the FM10 bible) then I used the TO for my relationship and did some scripting to seperate my people by job in a layout. I'm satisfied with it.

What I find strange is when I create a value list based on the TO and the contact table, I can have only what I want on the value list but all the remaining contact are "blank" on the value list so I have a long white space at the end of it. Is this normal?

What I'd like to understand is how come on the FM10 bible ii is said to have all contact together to avoid duplicating and there is no clear way to manage them. Still searching.

Thanks for your help.