5 Replies Latest reply on May 20, 2016 8:27 AM by Mike_Mitchell

    FileMaker 14 external file not closing?

    scottworld

      Hi there,

       

      I'm not sure if this is a problem in FileMaker 14, or if this is expected behavior?

       

      We have FileMaker Server 14.0.3 running on a Windows Server 2012 machine. It is hosting two (2) FileMaker 14 files: let's call them "Primary file" and "Secondary file".

       

      We then have FileMaker Pro 14.0.4 (64-bit) running on a Windows 10 machine.

       

      We are mostly working inside the "Primary file" 99% of the time. But on one particular layout (let's call it "Special Layout"), I needed to create a portal to show related records in the "Secondary file". So I created a relationship from the Primary file to the Secondary file, and put the portal on the Special Layout. (There is also a button on each portal row to "view" the record, which does a "Go To Related Record" and takes the user into that record in the external Secondary file.)

       

      Everything that I listed above is working just fine. No problems at all. Everything is working as expected. So far, so good.

       

      However, this is where the problem crops up: If I try to close the Secondary file, FileMaker doesn't close the file. It simply hides it instead of closing it. I immediately realized that this was happening because I had the Special Layout open on my screen, so of course, FileMaker needs to keep the external file open in the background to display the related records in the portal. 

       

      But, even if I switch to a COMPLETELY DIFFERENT LAYOUT in the Primary File that DOESN'T have a portal to the external (secondary) file on it, FileMaker STILL won't close the external (secondary) file. If I try to close the external (secondary) file, FileMaker simply hides the file instead of closing it. Even if the Primary File is on a layout that doesn't reference the external file at all.

       

      I'm not sure why this is happening!

       

      I thought that maybe there were some calculation fields in the Primary File that were referencing the Secondary File, which is why the external (secondary) file was still staying open in the background, but I used "2EmpowerFM Developer Assistant" to search through all of the field definitions, and there are absolutely no references to the Secondary File in the field definitions at all.

       

      I also checked the Secondary File for script triggers that might prevent the file from closing. There are absolutely no script triggers attached to the secondary file's file options nor any of the layouts in the secondary file. So I even went ahead and ADDED a brand new “OnLastWindowClose” script trigger to the Secondary File with one script step: “Close Window”. It still doesn’t work! When trying to close the Secondary File (while the Primary file is open and on a layout that doesn't reference the Secondary File), it still hides instead of closing.

       

      There is something about simply having the Primary File open that is preventing this secondary file from closing. If I actually close the primary file, it will close the Secondary File if it is hidden. And if I just open up the Secondary File on its own, I can close it. So there is something very weird going on.

       

      We don't actually WANT to leave the Secondary File open in the background, because it uses a different set of usernames/passwords than the Primary File... so for security purposes, we actually want the user to be able to occasionally close the Secondary File. (And yes, because of the different username/password situation, FileMaker will always prompt for the Secondary File's username/password when switching to the "Special Layout" in the Primary File.)

       

      But no matter what I try, I can't get FileMaker to close the Secondary File when I close the Secondary File while the Primary File is open. It only hides the Secondary File instead of closing it.

       

      Any ideas as to what might be going on here?

       

      Thanks,

      Scott

        • 1. Re: FileMaker 14 external file not closing?
          RickWhitelaw

          When closing a file FM will keep any related open but hidden. I'm assuming you know it's open because it is available under Show Window.

          • 2. Re: FileMaker 14 external file not closing?
            Mike_Mitchell

            If there's a TO for the secondary file on the Relationships Graph for the primary file, once it's open, it's open.

             

            I don't understand the security issue here. If the user has access to the secondary file, what's the harm in leaving it open?

            • 3. Re: FileMaker 14 external file not closing?
              scottworld

              This solution is a legacy solution that I just inherited from another developer, which was built in an older version of FileMaker when multiple files were necessary (prior to version 7).

               

              Yes, I can tell that it's open because it's available under "Show Window". It's weird that FileMaker would keep it open in the background if it actually doesn't need that file at the time. I remember a time in the past when FileMaker didn't operate like this... has this changed?

               

              The security issue is that this client has multiple employees all using the same computer (which is on a retail counter in a retail environment). So only certain employees have the ability to go into that Secondary File which has sensitive pricing information. They were using the "Re-Login" function within the Primary File in the past (which didn't close the Secondary File), so for now, I'm just having them close the Primary File (which also closes the Secondary File), and then having them re-open the entire system from scratch again.

              • 4. Re: FileMaker 14 external file not closing?
                scottworld

                Oops, I answered your question underneath Mike's response below. Not sure how the threading/notifications will work  here.

                • 5. Re: FileMaker 14 external file not closing?
                  Mike_Mitchell

                  scottworld wrote:

                   

                  Yes, I can tell that it's open because it's available under "Show Window". It's weird that FileMaker would keep it open in the background if it actually doesn't need that file at the time. I remember a time in the past when FileMaker didn't operate like this... has this changed?

                   

                  Not to my knowledge. It's been this way for as long as I can remember.

                   

                  The security issue is that this client has multiple employees all using the same computer (which is on a retail counter in a retail environment). So only certain employees have the ability to go into that Secondary File which has sensitive pricing information. They were using the "Re-Login" function within the Primary File in the past (which didn't close the Secondary File), so for now, I'm just having them close the Primary File (which also closes the Secondary File), and then having them re-open the entire system from scratch again.

                   

                  Well, you probably already know this, but it's poor security practice to share a computer. Nevertheless, I can see how that's needed in a retail environment.

                   

                  A manual logout / login is not really an ideal solution, since you're depending on people who shouldn't have access to deny themselves access. Fox, meet hen house. What I would suggest instead is you assemble some scripting that automatically performs a Re-Login on the secondary file whenever a user either needs access or navigates away from needing access. You can fire it via Script Triggers and have two versions: The one that prompts for credentials, and the one that logs in with a bare-bones minimal account. That way, users are forced to log in with their own credentials rather than being relied on to close a file.

                   

                  You'll need to think through the actual workflow, but this is, in principle, a better solution.

                   

                  HTH


                  Mike