I need some general guidance on field format/relationships.

I have a database with Memo information, another with personnel
information.
When a new memo is published I want to track or have people confirm
that they have read the memo. This can be a background (passive) or an
active process (check box or whatever). Ideally I would also like to
give people the possibility of rejecting certain memo types as - Don't
show me that one again so that certain memo can and will be
redisplayed and others can be hidden from a persons view.

Where does the join occur i.e. How can I achieve this. Have been
playing round with it for some time and cannot figure how to present
the memo number to the personnel database.

Any guidance, previous threads with similar needs, prebuilt solutions
etc which could be modified.

Note intend this as a web solution - once I have figured how to do it
successfully.

Des,

What you are describing is a so called many to many relationship. This calls
for a third table to connect you memo and personnel files. This file
contains both a relation to you memo talbe and a relation to your personnel
table.
In your memo table you create a relationship to this file based on the
keyvalue from memo (memonr). In the filemaker interface (more about the web
interface later) you can put a portal on the memo screen that you can use to
create records in the link-table (set your relation so that you can create
related records). The only field in this portal is the keyfield for
personnel with a valuelist attached that contains all personnel numbers.
This way you can set the intented audience right from the memo screen. Once
someone has selected all readers for a memo there are records created per
user per memo.
These are the record that you show from the other end (the personnel file).
If you add fields to this link table to set the status ("read", "do not
show", etc.) you can use them to determine if a memo is visalbe for someone
or not. You can do this by creating a calculated key in the link talbe that
matches a fixed key in the personnel file (e.g. in personnel file add a
field called "visable" that consists of personnellnumber + the number 1, in
the linktalbe create a similar field but calcultate the "1" based on the
status of the record). The next step is to base your relation between
personnel and the link talbe based on these new keys.
This should get you started.
Off course you can make it more user-friendly by adding routines like "show
to all readers" that will create records for all personnel at once.

For putting it on the web I would advice you to use CDML (not instant web
publishing) because there will be some more elaborate scripts involved in
order to make it user friendly. With the CDML setup you will need to change
a couple of things because not everything can be build the same way (e.g.
valuelists showing more than one field and conditional valuelists are not
supported), also depending on the scope of you project (nr of personnel
recors, number of memo's) you might consider changing the link routine
because it is not smart to use large valuelists in CDML because they are
loaded at once by the webcompanion wich can have an impact on of
performance.

I hope this helps to get you started.

Wouter.




"Des Keany" <d.keany@attbi.com> wrote in message
news:bb980f43.0311281052.2d8f9fd4@posting.google.com...
> I need some general guidance on field format/relationships.
>
> I have a database with Memo information, another with personnel
> information.
> When a new memo is published I want to track or have people confirm
> that they have read the memo. This can be a background (passive) or an
> active process (check box or whatever). Ideally I would also like to
> give people the possibility of rejecting certain memo types as - Don't
> show me that one again so that certain memo can and will be
> redisplayed and others can be hidden from a persons view.
>
> Where does the join occur i.e. How can I achieve this. Have been
> playing round with it for some time and cannot figure how to present
> the memo number to the personnel database.
>
> Any guidance, previous threads with similar needs, prebuilt solutions
> etc which could be modified.
>
> Note intend this as a web solution - once I have figured how to do it
> successfully.