6 Replies Latest reply on Sep 27, 2015 1:51 PM by JohnGagne

    Re-Login with Separation Model


      I have a solution with an interface file and a data file. There's a process in the interface file that creates and/or deletes accounts in both files.


      I would like to add a simple Re-Login script to the interface file so that a power user can change security levels without having to close both files first. Here's the problem. If I just run a re-login script in the interface file, the data file stays open with the original account/priv set. This is undesirable. I tried to close the data file after the re-login step in the script thinking that it would re-open using the current credentials, but I get an error 13 that the file is in use and can't be closed.


      Anybody know a way to force that data file closed so that it will re-open with the current interface credentials? Or some other approach to solve this?



        • 1. Re: Re-Login with Separation Model

          Hello, Jason.


          Have you tried using a relogin script in the data file and passing the credentials as parameters?



          • 2. Re: Re-Login with Separation Model

            Thanks for the reply, Mike. Yeah, I should have mentioned that my fallback position right now is passing the credentials and running a silent re-login script in the data file. I'm not a fan of doing that, or storing the credentials at all, but it's my only solution right now. Is that pretty much the only option when it comes to the separation model?



            • 3. Re: Re-Login with Separation Model

              Hi Jason


              We've recently installed a separated solution with a relogin facility and had to run a relogin script in the data file as Mike suggested. We did try going to layouts based on tables without external references and closing the data file, but it seemed fairly determined to retain the original user account.


              On some solutions we run multiple data files to a single interface file and not only run these scripts for relogin, but use a central human resources table that manages FileMaker accounts, privilege sets and passwords that uses a similar technique. This makes it much easier for administrators to add and amend accounts throughout all files.



              1 of 1 people found this helpful
              • 4. Re: Re-Login with Separation Model

                You don't have to store the credentials. What I do is throw up a dialog with global fields, then pass the results as parameters to change the password / create the account / whatever. Then relogin.


                Next time the user logs in, the new credentials pass through normally. The only thing that ever gets stored is the internal hash.





                1 of 1 people found this helpful
                • 5. Re: Re-Login with Separation Model

                  Thanks for the responses. I think down the road, I'll build in the idea where credentials get entered in globals and pushed around to all of the files. In this case, I think I'll stick with passing the credentials that are already stored until there's budget to rewrite that section.




                  • 6. Re: Re-Login with Separation Model

                    I am developing a solution with data separation, and I want to implement a LIMITED TABLE access calculation in the data file depending on who logs in.  I was having a nightmare trying to get the credentials in the interface file to push their way into the data file.


                    I was using a re-login script to save time during the development.


                    Then I decided to close down the solution and actually start it up again while performing a login with various credentials, and it worked fine.


                    The re-login script command did not seem as powerful as actually starting the solution and logging in.