6 Replies Latest reply on May 6, 2016 5:57 PM by RichardHurley

    2nd row of portal will not accept input


      Hello FileMakers,


      My work in FileMaker is intermittent. I need to ramp up my skills to make a relational database for my business and am having a problem creating new records in a portal that displays a join table from inside a parent table. Any help would be greatly appreciated.


      Attachment 1: Early in the project, when I was young and my brain was fresh, I got exactly the functionality I wanted: The empty portal displayed correctly with an active first line, showing the portal ready for input. As the first line populates, a second line in the portal becomes ready for data entry with nice, inviting fields.


      1) portal ready to enter.png


      Attachment 2: While teaching myself a lot of other stuff, I  apparently bunged up the functionality of this portal, as you can see below. The first line populates correctly, but no fields appear in the second line (which does appear active, however). Clicking in the second line does nothing. Displaying the join table in a separate window shows the first line data appearing correctly, but no joy after that.


      2) portal not ready.png


      I have checked the parent-to-join-table relationship in both examples. The child is set to allow record creation in both cases. I have searched in vain for the discrepancy between the two layouts. I suspect the problem is pretty simple, but I'm damned if I can find it.





      Richard Hurley

      Grass Valley MultiMedia


      late 2015 27-inch  iMac Retina 5K running OS X 10.11.4

      FileMaker Pro 14.0.5

        • 1. Re: 2nd row of portal will not accept input

          Richard,  if you go to a record that you know has multiple related records ... do they show on this new layout.

          eg. go to old layout and find a record with multiple related records ...go to that same record on the new layout.

          • 2. Re: 2nd row of portal will not accept input

            Thanks for the suggestion.


            Unfortunately, I saved my development file as a clone and then populated it with imported records from the old flat file I built in Filemaker 11 (the archaic data structure I am trying to expand). No multiple related fields in those imported records.


            It wasn't until after I imported my old data and attempted to add a second line to the portal that I realized I had a problem.


            I can search my backup system for intermediate files to try and find when the functionality broke, but that's a labor intensive, low likelihood-of-success strategy. I'm  new enough at this and FileMaker is a dense enough so that I assumed the problem was something basic that I bumped into in the dark. Heaven help me if I have wandered into a real swamp.


            FM Pro a splendid tool. I'm happy for the opportunity to expand my knowledge of it. I just wish it didn't make my head ache so.



            • 3. Re: 2nd row of portal will not accept input

              Go to Layout mode, select the portal and nudge it a few pixels. Do the portal fields move as well?


              If not, they're not recognized by the portal, so you have essentially a combination of an empty portal and some related fields outside of a portal.


              Nudge the fields back and fro and re-try with the portal until it does recognize the fields.

              1 of 1 people found this helpful
              • 4. Re: 2nd row of portal will not accept input



                1 field moved with the portal. 5 did not. How I contrived to uncouple the errant 5 I cannot imagine.


                I made another portal instance in the layout and it is behaving correctly.


                A few questions linger. If anyone can comment on them for educational purposes, I'd be grateful.


                1. I tried to restore the appropriate fields to the original portal after deleting the errant 5, but I couldn't find a way to do this. No such capability in "Portal Setup..." in the portal's contextual menu. And "Specify Field..." only let me replace the field that stayed properly associated with the original portal. (Option-dragging the remaining field and then swapping fields wasn't an option because the lingering field wouldn't take focus.)
                2. Is there a "best practice" about locating fields that can be placed in either a join table or its parent?
                3. I'm surprised that the correctly associated field didn't generate a new join table record, even though the other fields were not properly linked to the portal. I can't come up with a model of why this would be the case, unless I  just corrupted the portal to the point of no return.


                Many thanks for the help! I wouldn't have guessed disassociated fields in a million years. (I should have tested another portal instance built from scratch, however. I will now go stand in the programmers time-out corner and smack my head repeatedly with FileMaker 14, the Missing Manual.)

                • 5. Re: 2nd row of portal will not accept input

                  The fields in the portal have to be inside the first row of the portal. If you nudge the 'disassociated' fields down a pixel or maybe two, they might reassociate with the portal. I can see the border appears to be within the bounds, but if you click on each of the fields in layout mode, note where the handles fall.

                  Perhaps the handles are higher than the top edge of the portal, or they are grouped with something that falls outside the portal?
                  I find it easier to look closely at these things with increased zoom level.

                  • 6. Re: 2nd row of portal will not accept input

                    Thanks for the thoughts, Phil.


                    I did a lot of experimenting with graphic layout after I got my basic functionality built. It wouldn't surprise me if the portal lost connection to the fields as a result my placement of the fields in an unguarded moment. If that is indeed what happened, it suggests FM's code is a little brittle here. I can see bad things happening with the display of over-sized or mis-placed portal fields, but losing their linkage to the portal is unreasonable, given how easily the situation can occur.


                    In any event, I've gone on with the newly created portal and am almost done transferring my old data. Everything is working to expectation. The new relational structure will be a lot easier to maintain and provides much improved functionality for the  small publishing business I run on the side. I look forward to working with FM Pro more often.