3 Replies Latest reply on May 22, 2012 4:36 PM by karendweaver

    Script not working on a common-use layout

    jbrown

      Okay,

      So in my school, i created a page for teachers to see all their advisee students (see attached). Its a one-stop place for teachers to enter attendance, breakfast and deposits, with the money they earn each week.

       

      The system works pretty well, but the script that saves the deposits to the "checking" table works part of the time.

      Basically what happens is:

      Teachers type in the deposit amount from the kid's paycheck into the grey box at the far right, field Students::TempDeposit (see picture).

      At the bottom of the screen is a button that says "save deposits" The script takes the value in the TempDeposit field along with the student ID, goes to the Checking table, and creates the record there. It loops through the students, from the first to last.

       

      This works all the time when I'm doing it, but i usually am doing my testing at 5 am.

       

      When all teachers are here, though, using the same page (we all use it from 7:15 to 8:00 (its up on our computer to work with)) sometimes the script isn't working.

       

      Would the script fail or perform unexpectedly when everyone is using the page at the same time and potentially call this script at the same time?

        • 1. Re: Script not working on a common-use layout
          karendweaver

          Yes - you could be experiencing record locking.

           

          What is the table that this layout is based on?  Is there more than one record in this table?  Are all the teachers logging in to the same record?   Only one person can work in any one record at a time, and in certain cases, related records may also be locked..  You can Google "FileMaker record locking" to find a bunch of discussions and articles about this issue.

           

          You could add some script steps to make sure the teacher is not in a record that is already in use, or do some error trapping before posting the deposit, or some other method to avoid locking if this is the issue.

           

          Karen

          • 2. Re: Script not working on a common-use layout
            jbrown

            Karen,

            Each advisor pulls up only their advisee students. So teacher A will see only his students on the page. The script that goes to this page brings up only Teacher A's students.

            The layout is base on the students table, sorted by advisor. There is more than one record - its in list view. Its a place for the advisor to see all her students and mark attendance, breakfast, behavior, etc.

             

            I thought record locking only occured on the same record (which we've experienced here. People forget to click out of a record), not on records from the same table.

             

            The script has been rebuilt a few times. Not sure why its having problems.

             

            One more thing that just occured to me:  When a script grabs the id from one student, goes to the checking table and creates a record there, then goes BACK to the original layout, I have assumed that it simply goes to the same record that it was on before it went to the 2nd layout. I have to test that and see if that's the case.

            • 3. Re: Script not working on a common-use layout
              karendweaver

              If it's a list view, then you can still have issues if the user has a cursor in a field while clicking the button.  If the deposit amount hasn't been committed, then the new record creation can fail.

               

              Add a commit record step to the script as the first item. Another thing to check is if the record IS being created, but not including all the appropriate data from the student temp record.  If the record creation step is failing, then it could be several things, first to check would be permissions.  I would try adding error checking to the record creation step as well - if there is any error, save that info somewhere (I actually set up SMTP to send me an email with those kinds of errors and describe the user, the layout, the action and the error number... - that really helps).

               

              And yes, if it leaves the original layout and returns there, it should be going back to the same record

               

              If you can't get there with these suggestions, you might try posting the script..

               

              Karen