Hi. I am creating a meeting minutes database. It is related as follows;

Minute table--------Meeting number table--------Attendee table.

I add the minutes and the attendees via portals in the meeting record-so far so good.

Trouble is when i wish to print i need a layout based on the minutes. I put another portal into the title header of the layout and the minutes in the body.

Unfortunately meeting number (and associated dates) and the attendees shown are from the first meeting.

The reason I set it up this way was because the minutes sometimes carry over to the next meeting hence my portals (and report) only show "open" minutes.

I think I might need to redesign the database but am not sure where to go with it.Thanks

Edited October 2, 200817 yr by Guest

It almost seems as though you need another table that joins the meeting table and the minutes table. Each record in this table should contain the status since it seems that same minutes can be open for the current meeting but closed for the previous.

John--

You're probably right that you may want to redesign the structure. Pushing my brain against it briefly, I see a number of issues.

You have Meetings, Attendees, and Agenda Items. Each Meeting can have many Attendees, and each Attendee can go to many Meetings. Each Meeting has many Agenda Items, and an Agenda Item can be on more than Meeting. Each Agenda Item will have some sort of status. An Agenda Item could have Minutes taken each time it appears on an Meeting.

Assuming this is moderately close, you'll need a few more tables: you'll need a join table between Meetings and Attendees (to allow the many-to-many relationship), as well as one between Meetings and Agenda Items. To store the actual minutes, this second join table would also include a field to hold the Minutes for the Agenda Item.

Structured this way, it might make the reporting clearer.

I do not know what you actually have in the way of structures (your description is sparse in that regard); try searching for join tables and see whether that pushes you along.

David

are you both suggesting i have a relationship like this?

attendees<----meeting---->status---->minutes(agenda)

the relationship structure is - for every one meeting there are many attendee and many minutes. I am not sure i understand the purpose of the join table (search didnt enlighten me much).

I would think you need a structure like this:

Minutes >- Meetings -< Attendees >- Contacts

(NOTE: the notation "Parent -< Child" signifies 'one parent has many children, each child has one parent'.)

But you say that "minutes sometimes carry over to the next meeting" - so it wouldn't be correct to say that each minute has one meeting. However, IMHO 'minutes' are always specific to a meeting, and what carries over are agenda items. Which would bring us to:

AgendaItems -< Minutes >- Meetings -< Attendees >- Contacts

You could also make it simply:

Minutes >- Meetings -< Attendees

The difference is that here you need to spell out the agenda item for each minute, and the attendee's name for each attendee record, instead of selecting them from their respective tables.

You could also make it simply:

Minutes >- Meetings -< Attendees

The difference is that here you need to spell out the agenda item for each minute, and the attendee's name for each attendee record, instead of selecting them from their respective tables.

This is how I would like it work ( and had set it up that way) but when printing the number and attendees arent the most recent. I have attached a copy of my DB if any one is interested to have a quick look.

For info, The db opens up in the meeting record with a portal of minutes. Clicking the preview button takes you to a related minutes layout.

Minutes.fp7.zip

This is how I would like it work ( and had set it up that way)

I don't think you have. You seem to have a many-to-many relationship between Minutes and Meetings (I think - I don't understand your file too well, and it would take too much time for me to debug it).