8 Replies Latest reply on Jun 3, 2014 9:34 AM by Mike_Mitchell

    Odd behavior creating related records through portal


      Good day. I'm seeing a very strange behavior in one solution when users (including me) create related records through a portal. Here's the setup:


      Separated solution with parent table in current file, related table in separate file. Relationship is marked to allow creation of related records. User types in the first related field (step 1). But when you tab to the second field, the row into which you were typing disappears (step 2). You can type into the second field, but ... there's a problem (step 3).


      For some odd reason, the first related record created is not remaining in the portal display. I have another portal between the two files (to different tables), and it functions normally. Performing a Save as Compacted Copy made no difference. If the user commits the record between typing the first input and the second input, then everything functions normally, but ... that's a workaround.


      Has anyone seen this kind of behavior before? Any ideas what to do to fix it?





        • 1. Re: Odd behavior creating related records through portal

          I know it's not likely, but any portal or relationship filtering, or triggering that would explain the disappearance? Is there validation on the "Document No" field that might cause a hassle?


          It looks like the OnRecordCommit trigger is not firing when you tab between the fields. Not sure if this is expected behavior for external file referenced tables inside of portals, but in my experience I can't recall ever seeing this behavior.

          • 2. Re: Odd behavior creating related records through portal

            All good ideas, but no. That's what has me flummoxed. There are no triggers or validations anywhere. I even deleted the portal object and copied it from the one that's working (changing the pointers to the correct table), and that didn't seem to make a difference.


            As the Aflack duck might say, "Huh?"

            • 3. Re: Odd behavior creating related records through portal

              Have you tried doing this with the script debugger open, just in case?


              This doesn’t seem like corruption at all.


              Also, was this recently switched between versions of FM? with the addition of the refresh object script step, I would anticipate that some prior refresh actions are different now.

              • 4. Re: Odd behavior creating related records through portal

                Alas, the debugger indicates no scripts are firing at any point in the process.


                The solution was upgraded to version 12 about ... 7 - 8 months ago. A much more recent change was the separation of the database about 3 weeks ago. (Up until that time, it was a single file solution.) I separated out these two tables because they're external container tables and I was sick of dealing with the migration issues.  


                The process for the separation was (more or less):


                1) Duplicate solution

                2) Delete stuff you don't need from new external container file

                3) Repoint TOs for external container tables in parent file to external container file

                4) Delete container tables from parent file


                Something in there, maybe?

                • 5. Re: Odd behavior creating related records through portal

                  It's curious to me that you would duplicate the entire file to remove what you don't need, rather than just exporting the two tables you did need and building the external file from there.


                  I don't see anything wrong with that process though.


                  It doesn't seem like a permission / authorization issue either.


                  Sorry, not thinking of anything wrong. A simple way around it though would be an OnObjectExit script trigger on the fields in the portal that forces a commit/refresh.

                  • 6. Re: Odd behavior creating related records through portal

                    I'm almost to that point. But I thought there must be something structurally wrong for it to act this way; this is FileMaker 101 stuff here.  


                    And the duplication was to preserve some auto-enter, external storage path and calculation options. Six of one, half dozen the other, but I trust myself more to delete stuff I don't need rather than remember to fix all the stuff I do.  

                    • 7. Re: Odd behavior creating related records through portal

                      How is the relationship defined? What fields are required to create the record?


                      I have found similar problems with auto-create relationships where I set one field by script, then set a second field.

                      Setting the first field should populate the global on the "left" side of my relationship.

                      And this has worked in the past.


                      However, I find that in FM13 I must first set field; then commit; then set the second field (plus any other fields); then clear the left side selector to deselect the record.


                      What happens in your case if you set one field, commit, then re-enter that portal record and make any other edits?

                      • 8. Re: Odd behavior creating related records through portal

                        The relationship is defined based on an auto-enter calc (parent side) and a plain text field (child side). There are no required fields per se, although the child table does have a primary key (also an auto-enter calc). The parent record is already in existence prior to attempting to create the child record.


                        That said, the process you describe - set one field, commit, then re-enter - is our workaround at the moment. Oddly enough, we're still on version 12 here, though, so I'm not sure it's due to a version change. I don't remember having the problem before splitting the solution into two files, but the one table is still working normally. Only this table is acting up, and it's nearly identical to the one that's behaving (minus some global fields not related to the operation).


                        This one has me really scratching my head. Thanks for looking at it.