design issue

Hello,

I have a design issue that I am struggling with. (sorry for the long
post, and thank you for your patience)

Here is the context:

Multiuser, server-based FMP 9 solution for a large membership
association.

3 tables : Members, Meetings, and Registrations (a join table between
Members and Meetings)

On a meeting layout, a user can click on a Portal list of registered
members to see detail information for that member. In my current
solution, I simply have two side by side portals, one is a just a list
of names, the other is a one row portal with all of the detail. I use
Goto Portal Row to get to the correct detail, as they are sorted the
same.

This creates a few problems. One is that the user can scroll in the
detail portal and then it appears that the two portals are not synced
up. The other is that when I navigate between meeting records the
portals do not match up - the detail portal goes back to the first
portal row.

One solution would be to set a temp global key field to the
registrationkey for the particular registration that I want to see
detail on, and then display data based on the relationship between
this globalkey and the registration table. The problem here is that
when I navigate between meetings this globalkey will be the same for
all meeting records and as such will only work for the meeting that
globalkey was applied in last.

The next solution has the tempglobalkey not be set to global storage,
so that each meeting has its own value for the tempkey. The problem
there is that users looking at the same meeting will undo each others
preference as they are working.

So I think I need to link my User table to the Meeting table with an
intervening join table that will store the users current registration
detail that they were looking at.

Its just that when I start thinking about the scripting involved with
this, and the controls that have to start going into navigation, my
head starts to spin.

There must be a simpler solution!? Anybody want to take a shot at
this? Help!

Darren

Re: design issue

On Oct 26, 3:17 pm, Darren wrote:
> One solution would be to set a temp global key field to the
> registrationkey for the particular registration that I want to see
> detail on, and then display data based on the relationship between
> this globalkey and the registration table. The problem here is that
> when I navigate between meetings this globalkey will be the same for
> all meeting records and as such will only work for the meeting that
> globalkey was applied in last.


When you define the new relationship between your Meeting table and
your new Registration TO, you create TWO criteria for the
relationship. The first you've got, a global (set to the Reg ID by a
script) in Meetings to the Reg ID in Registrations. The second
criteria is the Meeting ID in Meetings to the Meeting ID in
Registrations. When the user changes records, the Meeting IDs won't
match.

Re: design issue

Yes, thank you for that explanation as it describes why it does not
work. I do understand this.

My question really is how do I solve the problem? Any Ideas?

On Oct 26, 6:27 pm, Grip wrote:
> On Oct 26, 3:17 pm, Darren wrote:
>
> > One solution would be to set a temp global key field to the
> > registrationkey for the particular registration that I want to see
> > detail on, and then display data based on the relationship between
> > this globalkey and the registration table. The problem here is that
> > when I navigate between meetings this globalkey will be the same for
> > all meeting records and as such will only work for the meeting that
> > globalkey was applied in last.
>
> When you define the new relationship between your Meeting table and
> your new Registration TO, you create TWO criteria for the
> relationship. The first you've got, a global (set to the Reg ID by a
> script) in Meetings to the Reg ID in Registrations. The second
> criteria is the Meeting ID in Meetings to the Meeting ID in
> Registrations. When the user changes records, the Meeting IDs won't
> match.

Re: design issue

On Oct 26, 4:48 pm, Darren wrote:
> Yes, thank you for that explanation as it describes why it does not
> work. I do understand this.
>
> My question really is how do I solve the problem? Any Ideas?
>
> On Oct 26, 6:27 pm, Grip wrote:
>
> > On Oct 26, 3:17 pm, Darren wrote:
>
> > > One solution would be to set a temp global key field to the
> > > registrationkey for the particular registration that I want to see
> > > detail on, and then display data based on the relationship between
> > > this globalkey and the registration table. The problem here is that
> > > when I navigate between meetings this globalkey will be the same for
> > > all meeting records and as such will only work for the meeting that
> > > globalkey was applied in last.
>
> > When you define the new relationship between your Meeting table and
> > your new Registration TO, you create TWO criteria for the
> > relationship. The first you've got, a global (set to the Reg ID by a
> > script) in Meetings to the Reg ID in Registrations. The second
> > criteria is the Meeting ID in Meetings to the Meeting ID in
> > Registrations. When the user changes records, the Meeting IDs won't
> > match.

Read my post again. I was giving you the answer or I don't understand
your question.

Create a relationship with two criteria.
Meeting::GlobalRegID = Registration::RegID
Meeting::MeetingID = Registration::MeetingID

Users clicks on a record from the portal, script sets
Meeting::GlobalRegID to that person's RegID. Info shows in that
portal. If the users moves to another Meeting record, the second
criterion won't match and nothing will show.

Re: design issue

Yes, sorry for the miscommunication. Your solution is what I have in
place now and it behaves as you describe.

I would like to be able to navigate between the meeting records and
have the same registration detail record show when the user returns to
a meeting record. Basically want to return the user to where they
left off.

Something like this:
User looking at Meeting Record A
User clicks on name of Sally to show Sally's registration detail for
Meeting A
User Navigates to another meeting record B
User clicks on Joe's name to see Joe's registration detail for Meeting
B
User returns to Meeting A and Sally's detail is still showing.

This could be accomplished by storing the last registration detail
viewed for a meeting in the meeting record in a non global temp key.
However in a multi-user environment the users will step on each other
since the temp key is not global.

So, from my original post:
I think I need to link my User table to the Meeting table with an
intervening join table that will store the users current registration
detail that they were looking at.

Its just that when I start thinking about the scripting involved with
this, and the controls that have to start going into navigation, my
head starts to spin.

Is there a simpler solution?


>
> Read my post again. I was giving you the answer or I don't understand
> your question.
>
> Create a relationship with two criteria.
> Meeting::GlobalRegID = Registration::RegID
> Meeting::MeetingID = Registration::MeetingID
>
> Users clicks on a record from the portal, script sets
> Meeting::GlobalRegID to that person's RegID. Info shows in that
> portal. If the users moves to another Meeting record, the second
> criterion won't match and nothing will show.- Hide quoted text -
>
> - Show quoted text -