7 Replies Latest reply on Oct 20, 2009 11:10 AM by philmodjunk

    Buttons in Portals



      Buttons in Portals


      Okay, another problem with portals. Once again, I am using FileMaker Pro 10.0v3 on Mac OS 10.6. I am pretty new at this (started a few weeks ago) but I am familiar with relational databases and SQL.


      So there's 3 tables, pictures, info, and album. I have the relationship set up as:


      album » info » picture


      The picture table contains a picture, the info table contains info about that picture, and all 3 tables have a field called "album name" which is being used as a key to connect all 3 tables.


      In the album table, I made a portal which is getting all the related pictures and listing them out. The problem I'm running into now is I want the pictures in the portal in the album table to be buttons that lead to the related record in the picture table. Unfortunately, all the buttons in the portal all lead to the first record on the picture table, rather than the record associated with the picture. I tried making a separate button to do this but it does the same thing. Anyone know what I can do?


      I'm doing this by right clicking the picture in the portal, selecting Button Setup, Navigation...Go To Related Record, Specify, get related record from picture, show record using layout picture, everything is not checked. 


      Edit: Ah, I see. It's giving me the first record of the found set of related records, not the first record in general.

        • 1. Re: Buttons in Portals

          Why do you have both an info table and a picture table? Is there always just one info record for every picture? If so, you could simplify your table by putting the info and picture fields in the same table. This might, get your GTRR step to work as expected also. Otherwise you might need a script:


          Go To related record //specify options to go to the related info record

          Go To related record //specify otpions to go to the related picture record from the info record.


          Go to relate record is powerful, but quirky and is poorly documented by filemaker. Uninformed use of this script can lead to nasty consequences. To learn more about it, see this link:


          The Complete Go To Related Record

          • 2. Re: Buttons in Portals

            The picture is in the info table too, and they're usually pretty big pictures and they're shrunk down in both the album and the info table. That's how the client wants it. Also the client wants to be able to click on the picture in the info table to see an enlarged version of the picture, and I couldn't really find a way to do that so I just made it a separate table and made it really big there.

            • 3. Re: Buttons in Portals

              "The picture is in the info table too, and they're usually pretty big pictures and they're shrunk down in both the album and the info table."


              This doesn't make sense to me. They'll be "pretty big" no matter which table you store it in. If there's always only one picture for a given info record, then merging the two tables will not affect this at all. The dimensions of the field you use to display a picture have no connection whatsoever with what table stores the picture or a reference to a picture (if you choose to store them as separate files.)


              You are aware that tables and layouts are two different things in Filemaker?


              I was assuming the following table structure:


              Album, one record = many pictures. one record = many info records.

              Info, one record describes exactly one picture

              Pictures, one record has a container field that stores either a picture or a file reference to a picture plus a key field (album) that links it to an Album record.


              If this is correct, then the Info and Pictures tables can be merged and this will make them a little easier for you to work with.

              • 4. Re: Buttons in Portals

                Is there a way to make a small version of a picture linked to a full sized version of it? Like a gallery or something? I really don't want that extraneous picture table if I can help it. 


                In the album table, it's the picture except in the layout the field is pretty small, and the picture is resized to accommodate. So I had to make a separate table so that I can have both a small version and a big version of the same image. That's all.

                • 5. Re: Buttons in Portals

                  I don't follow why you would place any picture (container) fields at all in your album table. You can define multiple fields in the same record or relate to multiple picture records. Don't see any advantage to placing a picture field in the album itself. (When I refer to "size" I am referring to the size measured in megabytes or pixel dimensions not the size of the field you'd place on a layout.)


                  Here are two possible examples of how you might set up your picture table:



                  PictureID (serialnumber)

                  Thumbnail (container)

                  Midsize (container)

                  Fullsize (container)

                  Description (text)



                  PictureID (serialnumber)

                  ImageID (number or name)

                  Size (text or possibly a number field)

                  Picture (container)

                  Description (text)



                  • 6. Re: Buttons in Portals

                    Ah, okay, I think I see where the confusion is coming from.


                    Well, this database is going to go online and viewable by a bunch of people. It's suppose to be a gallery, but every CMS we tried was missing features we need (poor or missing searching and organizing function, generalized description fields with no customization, etc). FileMaker seems to be the best choice after that.


                    The people viewing the website are not computer savvy, and it's probably safe to say they don't know what databases are outside of maybe Microsoft Access. So I'm trying to make it easy to look at and navigate, so in each of the albums, I want thumbnails of all the images that are currently in the album, and each of the thumbnails clickable to lead to the full sized version of each of them. I couldn't figure out how to do this other than make a separate table and make the image big there (in terms of dimensions), and then make each thumbnail a button that goes to the related records. The problem I have though is that it always goes to the first entry among the related records rather than the particular image that I clicked on.


                    It's suppose to act like a gallery, basically, except I'm making it in FileMaker.


                    If this was just a normal database in maybe SQL or something, then yeah there's no need to have pictures in the album itself, just have it in the picture table and link the two tables together.

                    • 7. Re: Buttons in Portals

                      Dimensions as in the field needs to be say 4" x 6"? If so, I repeat, this has no bearing whatsoever on what table you use to store the images. To change the dimensions of the field in which you store an image you can simply resize that field to the size needed on any layout--providing the stored image has sufficient resolution to display the image clearly at that size.


                      I don't think you should store any images in the album table. This has nothing to do with whether or not the users are computer savvy or not. It's a matter of basic relational database design.


                      You need to answer some basic questions about your data and those answers will determine the structure of your tables.

                      1. Can a given picture appear in more than one album? If yes, then you shouldn't store any image in an album record. Instead, you'd store them in a related table of images and use a relationship to control which image appears in a given album. Even though you've stored the image in a different table, you can still display that image on a layout based on your album table.
                      2. How many info records do you need to document a given image? If only one info record is needed for any picture record, then you can put the info fields and the picture container field in the same record. There's one exception here, if you store several copies of the same image--each with a different resolution (one might be a low res thumbnail and one might be a high res copy for popping up in large format) but only need one info record, then a separate table for info records is logical as you can then link a single info record to several records that store different copies of the same image.