Scripts strangeness

Discussion in 'Optigold ISP' started by samnaugler, Aug 2, 2005.

  1. #1
    I have been receiving a number of complaints about problems with Optigold over the last month or two, weird patches of slowness, client crashes, long [sometimes unending] spells with the wavey-arrow, etc... but have been unable to pin down a cause. Today I did hear about a duplicable behavior, and its fix has me a little concerned.
    Billing reported that running "Auto Server Cancel" on an account would freeze their client for about 2 minutes. I tried it myself and that was indeed the case. (It does take time for the telnet cancellation to complete and the message "Successfully Cancelled" or "No such user to cancel" does sit on screen for a good long while, but this is really different...after all that had completed the client would still just sit there, OG frozen, parts of the windows whited-out [which ever was in front...such as the pull-down for scripts..changing from text to all white] rest of the computer still useful, for about 1.5 to 2 minutes.)
    A duplicate set of .FP5s off-network and opened locally on a box did the same thing (I noticed a "Filemaker (Not Responding)" up in the blue Windows line during the freeze, and the [big, fast] processor was using about 50% for Filemaker Pro.exe at that time) more or less ruling out filemaker server or a network problem (although it ran the same telnet, so conceivably if that connection were the cause it could still be something there).
    Noticing that the (exactly the same but for one word) hold script did not have the problem, I then decided to change the command that the cancel script runs to be the same as the hold script.....and after saying that the account had been placed on hold, it locked into a 2 minute freeze. I then changed the hold script to run the cancel command instead of the hold, and it cancelled an account fine, no freeze. SO, I clicked "Duplicate" in the cancel script and disabled the original "cancel script" and enabled the "cancel script copy", and the freeze has gone away.
    On my off-network copy I set it all back to the way it started (and tested that the problem is still there) and ran a recover on my Events.fp5 file, it shrank from 603k to 597k (really quickly) but did not correct the problem.
    I am concerned that there may be farther reaching implications surrounding this fix. What do you think?

    Sam - FSI
     
    samnaugler, Aug 2, 2005 IP
  2. digitalpoint

    digitalpoint Overlord of no one Staff

    Messages:
    38,334
    Likes Received:
    2,613
    Best Answers:
    462
    Trophy Points:
    710
    Digital Goods:
    29
    #2
    If it's happening on an isolated copy (no other users connected to it), I think the best place to start would be to recover all the files (or at least your major ones... MainMenu.fp5 for sure). Recovering the Events file probably wouldn't do much because it's just a repository of data defining the event. If there is slowness in pulling some variable you use in your event, the issue is going to be with the file it's pulling from.
     
    digitalpoint, Aug 2, 2005 IP
  3. samnaugler

    samnaugler Peon

    Messages:
    76
    Likes Received:
    0
    Best Answers:
    0
    Trophy Points:
    0
    #3
    Okay, on my isolated copy I recovered all files (in groups so as to isolate which one besides Event_.fp5 might be the culprit) and there was no change (fully recovered I get the same behavior).

    Something reassuring though, I isolated a copy of my fp5's from February, tried them, no trouble on the cancel script, then I copied in my offending Event_.fp5 and tried again and got the bad behavior....indicating, I think, something was just "screwy" with that file that the "duplicate" trick fixed.

    Sam - FSI
     
    samnaugler, Aug 4, 2005 IP