3 Replies Latest reply on May 23, 2014 12:35 AM by erolst

    Showing related table data without a portal - Image Container(s)

    c0nsilience

      Ok all, another newbie question here.

       

      I'm trying to have images displayed and added in containers on a tab control of a layout (HVAC) with a container field (Doc_Attachment) from a related table (Documentation). I'm having luck displaying one image, but when I try to display multiple images, it is the first image repeated in multiple containers. Ideally, I'd like to have users click on the container in the tab control to drag and drop multiple images into multiple containers.

       

      In the past, I just would've created container fields for the images in the primary table (i.e., HVAC_Image1, HVAC_Image2, etc.), but I did not create these tables and I'm trying to adhere to what the developer's done re the layout (yep, our company's first teambuilt fm db!)

       

       

      What am I doing wrong? I'm assuming it's something simple that I've just overlooked. I've attached screenshots of the relationship and the container.

       

      Any/all help will be more than appreciated. Thank you!

       

      Screen Shot 2014-05-22 at 9.07.19 PM.png

       

      Screen Shot 2014-05-22 at 9.08.44 PM.png

        • 1. Re: Showing related table data without a portal - Image Container(s)
          erolst

          You need to use a portal to show multiple related records. A related field outside of a portal will always come from the first related field per the sort order of the relationship, regardless of how many times you put it on the layout (which of course has its uses; and then there is the many side of a one-to-many relationship, where you don't need a portal to the parent table, since by definition it only has 1 related record.)

           

          I'm not sure about your thread title – are you already suspicious/aware that you indeed need a portal, or are you implying that you think you cannot use a portal …?

           

          If you need empty containers to be filled just in time, create the required number of related (empty) records via script, then let the users populate them via portal; or display them in a list layout; or script a popup (FM13) that show the next empty, or a global field … as usual, there are several ways.

           

          What's your developer saying re your issue?

          • 2. Re: Showing related table data without a portal - Image Container(s)
            c0nsilience

            erolst,

             

            Thank you for the reply and for clarifying some issues.  I was 90% sure a portal would be necessary, but not 100%.  The developer thinks we should keep images/files/documentation outside of the main table (the table the layout is showing records from), place them in the documentation table, and pull them to the required records, just in case the db file size grows.  They built the tables and have a solid SQL background.  I don't know enough about SQL to know if this would work precisely with FileMaker. 

             

            My past experience tells me that if you have images, for example, of a bike, you would want those container fields to be in the related table (Asset_Bicycle), eradicating the need to use a portal whatsoever (assuming that 'Asset_Bicycle' is the table you're showing records from). 

             

            Is this a bad practice?

            • 3. Re: Showing related table data without a portal - Image Container(s)
              erolst

              c0nsilience wrote:

              My past experience tells me that if you have images, for example, of a bike, you would want those container fields to be in the related table (Asset_Bicycle), eradicating the need to use a portal whatsoever (assuming that 'Asset_Bicycle' is the table you're showing records from).

               

              Is this a bad practice?

               

              I'm afraid I don't understand the question … In my past experience, using related records has rarely "eradicated the need to use a portal whatsoever". But I suspect I know where you're coming from. See it like this:

               

              If you have an Invoices/Orders table, your line items are stored as related records. While you're creating and editing an invoice/order, you'd typically display them in a portal on the Invoices layout. When you print an invoice, OTOH, you go to a LineItems layout, show all line items for that invoice (with some sorting, grouping thrown and summarising thrown in), plus the related fields from the related invoice record (just one, no portal necessary), and print.

               

              As you see, it's a matter of workflow and convenience; sometimes you want to see the related records within the context of their parent, another time within their own table as a list (and sometimes within their own table in a portal, but let's not go there …). 

               

              But let me add on a (pun notwithstanding) related note: what's probably a bad practice (provided that function follows name) is to have a table Asset_Bicycle.

               

              You should have one table Asset_Images, holding whatever images you have for assets (where a next step could be to use one Images table for all images, regardless of parent table).

              1 of 1 people found this helpful