Portal Help

[faaslave]

I must be doing something wrong with my relationships because the portal doesn't seem to work.

Under the chapters, I am trying to list the members of that chapter using the portal.

File attached

Thanks Dave

[Fenton]

Because the relationship from Members to Chapters is on the ChapterNum, not on the MemberID. There should not be a MemberID in Chapters.

What you're saying is that 1 Member belongs to 1 Chapter. Thus the Chapter is an "attribute" (field) of a member. A Chapter has many members, hence it cannot have a member field, which could only hold 1 member.

If, however, a Member can belong to more than 1 Chapter, then you need a "join" table, with both a MemberID and ChapterNum, which both files look at (to get the IDs and rows) and through (to reference names in the further table).

BTW, you have a redundant ChapterID. Either use one or the other.

[faaslave]

Thanks Fenton

I will try and fix it

Dave

[faaslave]

I guess I am still confused.

I have a table with Members, and their data

Then I have a table with chapters, Number,name, who's president, treasurer, etc.

Many Members to one chapter

I have done this with invoices, lineitems, customers before, but I am confused with this one, since I am not using an invoice.

When I am done, I want to have the information on the member layout showing the chapter info for that member. If a member changes chapters, I want to be able to pull up the member and select a new chapter and it is updated.

So what exactly is in this join table, just a link to the memberid,and chapterid?

Then build the layout based on the join table?

I am confused

Thanks Dave

[Fenton]

A join table is just that. It may contain ONLY the 2 ID fields. Its purpose would be to handle the situation where a Member can be a member of more than one Chapter. If that is not happening, then you don't need or want it.

You'd just need the ChapterID (Num, whatever) in the Member record. But the portal's relationship from Chapters to Members is on the ChapterID. There is NO MemberID in the Chapter table.

[faaslave]

Thanks Fenton,

I have attached what I tried to do.

I made the join table, but I can't seem to get the relationship from the member table to the join table to be a many to one relationship.

What I am hoping to do is to have the chapternumber filed from the chapters table displayed in the on the member layout so when a members record is displayed, I can click in the chatper number field, select the one I want, and information about that chapter can be displayed on the member layout.

Also on the chapter layout, I could have a portal showing all members associated with that chapter.

I think I have it like you said, but something isn't right.

Dave

[-Queue-]

You don't need a join table if a member can only be associated with a single chapter at a time, as Fenton said.

I've removed the join table and added a ChapterNum field to the members table so you can create a direct relationship to it. I've changed the related ChapterNum field to be the local ChapterNum field on the members layout and the Region to display the related field. I also removed related value lists that you don't need since the information will come directly from the related table, and I added the portal in chapters to display related members, as you requested.

[-Queue-]

Hmm. I can't seem to upload the attachment. Something screwy is going on with the forums. I'll try again later.

[faaslave]

Thanks -queue-

I will be looking for it.

Dave

[faaslave]

Since it can be done both ways and knowing that I am going to be adding to this database, which way is more advantagous?

No join table

or use a join table?

One way must be the prefered way.

Dave

[Fenton]

There is not so much a "preferred" way, as a "what you need" way. In other words, if you don't need it, you don't need it; and it is usually best to only put what you need into a solution. A 1-to-many relationship does not need a join table. A many-to-many relationship does.

So the question is, "Will it ever be many-to-many?" You're the only one who can answer that, for your particular "business rules." But it seemed to me you were saying, "No, a member is a member of only 1 chapter."

The only reason I mentioned it in the first place (and I kind of wish I hadn't :-) is that often these situations turn out to be many-to-many, but people tend to not tell us about that right away. So I was partly trying to ask, and partly "teaching," because you'll need a join table someday :-]

[faaslave]

Thank You very much.

After playing with the table now, by the way I am not using the join version, I noticed that when you are on the chapter layout, it is easy to accidently change the chapter number. When on this layout, it seems logical to select a chapter, and expect the rest of the data to change displaying info for that chapter. Instead, it is just going to change the field to the new chapter number.

So while I need this layout for maintenance, I would like a different layout that does what I want. So I made a self-join with the chapters table. I am close to what I want but not there.

How do I make a layout where data is not entered, just viewed? There are many layouts I will eventually want, where a user can select different options from a pull-down menu, and applicable data is displayed. Like you find on many web sites.

The problem is, when I format a field so that edit can't take place in browse mode, you can't even select a value in the field. I don't want to force the user to use the find command every time just to see data.

Chapter Number at the top with a pop-up list, The user selects the chapter they want to look at, and presto you are viewing the data. that way the other layout is, only used when a need is there to add, delete, chapter etc.

Thanks a lot

Dave

[-Queue-]

Make the variable Chapter Number field a global that is self-related to Chapter Number. Put a 'Go!' button next to the field that triggers a Go to Related Record [show only related; "yourrelationship"]. Users select from the pop-up list, then click the button.

You can make your real Chapter Number field a button attached to a script which validates whether a Chapter Number has already been specified and warns the user if it is not empty, allowing them to cancel before changing it. If they don't cancel, the script uses Go to Field [Chapter Number] to trigger the display of the list. Remove the field from the Tab order and disallow entry to it in Browse Mode.

[faaslave]

O.K.

So I have a self-join table, lets say chapters2

On this table, I make the ChapterNumber global

I build the layout based on the chapters2 table

Then this global chapternumber field is the one the user will be selecting to pick a chapter

The other related fields I want displayed will be from the chapters table

On the chapters table I made the field unique, so it would warn if someone was making this mistake.

The script part I am a little confused what you mean. I think maybe I am trying too hard to fight the find feature since that is what it is for. But I have seen this used alot on the internet. A layout comes up with selectable fields, you click in a field and up comes the menu, you select one, and presto the related fields are displayed. I have also seen ones that require you to pres GO after making the selection. But the first way seems the nicest.

Maybe this is just beyond the capabilities of filemaker. It is apearant that this is beyond my capabilities. haha

Isn't this is a common thing used by people hosting on the web?

When I get home I will try out your suggestions, but I don't think i am fully grasping what you are saying.

Thanks JT,

Dave

[Fenton]

I redid a stripped-down version of your file to include a global "find chapter." FileMaker can behave much like a web page, if you use a global field. All values on the layout are based on the global _gChapterNum; including the portal's relationship and its fields.

I also redid the Member to Chapter relationship to just use the ChapterNum. Otherwise it just gets too complicated (using the ChapterID, which is basically a serial number).

The problem with trying to "blend" this web-like behavior with FileMaker Finds and data entry (which you don't really do much of on the web, other than forms, which are then "sent."), is that navigation must be carefully done, or else it's just confusing, and no one knows what's going on.

I would think that after initial data entry, there would be little editing in the Chapters table. I added a "unique" validation to the ChapterNum anyway.

The problem with the global "find the ChapterNum" layout is that it's really ONLY good for that. It does not work at all for general Finds.

FAAMA3.zip

[faaslave]

Thanks a lot Fenton,

I will take a look at it and report back

Dave