2 Replies Latest reply on Sep 21, 2016 10:20 AM by justinc

    Strange Script Behavior

    addison

      I have a database with two privilege sets: Full Access and Technician. Technician is a custom privilege set. When one of our technicians logs in with their username and password, it triggers installation of a Technician Custom Menu that doesn't allow them to create or delete records, and changes the "view all records" button to only show them the records tied to their login (in order to hide the "No Access" records from view). The database in question is a time card database, and technicians primarily use FileMaker Go on iPads to access it.

       

      The database and logins seem to be working fine, except for one instance that I cannot replicate or figure out. One of our four technicians logged in in the morning, which triggered the creation of a time card for the day. If/when he logs in later that day, it should automatically check to see if a record for the day exists, and if it does, it takes the technician to that record instead of creating a duplicate.

       

      However, when he logged in at the end of the day, he says that he only saw a blank record, and the "show all" part of the menu was not there. He hit the "new record" plus sign, and it allowed him to create a new record, effectively creating a duplicate for the day. He could also see "No Access" records (but not the information in them, due to the security settings). We also have an audit script running, but I know it did not run during this portion of time, because there is no audit information on those two records.

       

      I have since tested his account as well as some other dummy test accounts in an effort to replicate the situation, but all is acting the way it should be.

       

      I just want to be able to prevent this from happening again, as it's confusing for employees. I imagine it might be a FileMaker Go glitch, but I haven't been able to find a similar question on here.

       

      Thanks for any help.

        • 1. Re: Strange Script Behavior
          deninger

          Without seeing the script and the permissions, it is difficult to give a specific answer. You did mention FM Go, so I will point out the obvious. Did you check all script steps for FM Go compatibility? Something like this could fail simply because one step somewhere doesn't execute on that platform.

          • 2. Re: Strange Script Behavior
            justinc

            I like Deninger suggestion - an incompatible script step can cause a whole script to stop processing, depending on what the "Error Capture" setting is.

             

            Otherwise, since you haven't been able to replicate the problem yourself, I would suggest a general debugging-auditing process: create a little script that logs (to a special table) an event with some key data; put calls to this script in various locations throughout your system.  Perhaps logging the start and end points of various scripts - put in hooks in your startup, navigation, and record creation scripts.  I'd include the privilege set and accountname of the user that is logged in when this new script fires.  It's a bit of a shotgun approach, but it should help you to start narrowing down where the problem lies.