Jump to content
Sign in to follow this  
faaslave

Portal Help

Recommended Posts

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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 :-]

Share this post


Link to post
Share on other sites

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.

crazy.gif

Thanks a lot

Dave

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×

Important Information

By using this site, you agree to our Terms of Use.