2 Replies Latest reply on Oct 22, 2013 7:12 AM by DomingoUgarte

    Scheduled hourly backup may have affected a script execution



      Scheduled hourly backup may have affected a script execution


           Yesterday we experienced an issue in our time tracking system. I have a FMServer 12 installation conducting hourly backups on the hour from 6am to 8pm. I received a frantic call from one of our data entry personnel responsible for entering and maintaining time. The issue was that somehow someway all the clock-in times for all employees were changed from their original values to 8:10am but only for tickets created from 10/14 until 10/21 (We have data going back as far as January 2013). Under pressure to resolve this. I looked back at the hourly backups starting from the latest 10/21 @ 5pm and went backwards. I found that my 3pm backup had indeed been the last correct backup. Long story short, I exported my primary key field and the clock-in field to an xlsx file, created a new temporary table in my production database, imported those values, created a relationship, and effectively overwrote all 8:10 values to their correct ones. I also noticed that the last modified time value for all the erroneous 8:10am records, values were set to 10/21/2013 3:59:59 PM. This is precisely before backup time. 

           Still with me? Well I have a history table that tracks changes performed on every field modified in my time entry layout. After carefully investigating the event leading to this issue, I noticed that one of the operators, executed this script below precisely at 10/21/2013 3:59:59 PM. It is a button that allows the operator to apply a clock-in time (set from a global time field in my Tickets table) across all the related records in my  EmployeeLines table. Somehow this must be the culprit.

           Is this a bug or is there something I am missing in my script?



        • 1. Re: Scheduled hourly backup may have affected a script execution

               You have what looks like an extremely dangerous script here.

               Here's why:

               You have a Go To Related Records step without any check to confirm that related records actually exist. If there are no related records, the script continues execution as though the GTRR step was skipped--leading to a Replace field contents operation that could be proceeding from the wrong context on the wrong set of records.

               Can't tell if that was a factor in what you had happen or not, but I'd add either a test for the existence of related records or a check to make sure no error code was returned by GTRR to be on the safe side here.

          • 2. Re: Scheduled hourly backup may have affected a script execution

                 Bingo!!! Thank you once again Phil. I overlooked this. I ran one of my backups offline and tested a scenario where the GTRR will surely fail and sure enough you were right; the replace field contents ran anyhow and changes ALL my clock-in times 

                 This serves as a reminder for myself to go back into old scripts and implement safety nets like these. The time of script execution played no role either so that is good news