Results 1 to 6 of 6

Thread: Status 4 errors with a weird fix

  1. #1
    Join Date
    Mar 2009
    Posts
    785

    Default Status 4 errors with a weird fix

    Hi all,

    I apologize for the vague description of this post, however we can't quite identify exactly what the problem is. Here is as much details as I can give

    VDF 16.0
    Windows Server 2012
    Multi-user system, VDF embedded data

    On this one particular customer's environment (it doesn't affect all our customers), when he executed a series of steps in our app (Let's call it "MainProgram"), he would then get a bunch of status 4 errors. The status 4 errors happened on either "Find" or "Reread" command.

    One of our programmers was able to narrow it down that to the fact that we called "Runprogram Wait" before those errors showed up. We were executing another VDF program (Let's call this program "SideProgram") within the same directory. We have had bad run-ins with "Chain Wait", I thought "Runprogram Wait" might cause similar issue, therefore I changed all the calls to "ShellExecute" instead. That didn't fix the problem. In case it wasn't clear, the status 4 errors happened inside "MainProgram". Also, whenever we do "finds"/"saves", we always to the "clear"/"find"/"reread" sequence.

    Then we tried replacing "SideProgram" with a C# dummy program. Afterwards there were no more status 4 errors.

    At this point, the conclusion is that when one VDF program (caller) executes another VDF program (callee), the file buffers of the caller might get messed up afterwards.

    To workaround all the status 4 errors, we have to close all the VDF files in the "MainProgram" before executing the "SideProgram". After executing the side program, we would re-open all the files. That fixed the problem.

    To all the VDF old timers out there, does this situation ring any bell?

    Thanks in advance,

    Frank Cheng

  2. #2
    Join Date
    Feb 2009
    Posts
    4,609

    Default Re: Status 4 errors with a weird fix

    It's probably not related but it reminds me of this long thread

    https://support.dataaccess.com/Forum...p?t-40248.html

    and the manipulation of the floating point control value
    Success consists of going from failure to failure without loss of enthusiasm - Winston Churchill

  3. #3
    Join Date
    Oct 2014
    Location
    Heerlen, NL
    Posts
    186

    Default Re: Status 4 errors with a weird fix

    Hello Frank,

    In the past we had a customer with intermittent status 4 errors, after a very long search we found that the problem was caused by heavy machinery used next door. As the machines where started up they caused a dip in the net power and if that happened during saving the saving was broken off in the middle of the save and the status 4 errors came up. Putting in a UPS solved that problem. Have you tried to wait a little while before starting the callee program to give the caller the time to finish a save procedure?

    Regards,

    Leon Raafs

  4. #4
    Join Date
    Feb 2009
    Posts
    1,963

    Default Re: Status 4 errors with a weird fix

    Hi Frank,
    Is this a "it was working fine and then one day it started breaking" thing or a "it's always been broken" thing?
    Richard

  5. #5
    Join Date
    Mar 2009
    Posts
    785

    Default Re: Status 4 errors with a weird fix

    Hi Richard,

    I think the customer said it's always been broken, but the exact reproducible steps were difficult to nail down. When they finally did nail down the steps, we could get it to happen probably on every 3 to 4 tries.

    Frank Cheng

  6. #6
    Join Date
    Mar 2009
    Posts
    785

    Default Re: Status 4 errors with a weird fix

    Hello Leon,

    Thank you for the reply. The status 4 error is now reproducible on the customer's machine at any time, so that kinda rules out the power fluctuation situation.

    It is definitely a timing / caching issue. I think if we pop up message box everywhere and wait a minute or so, no more status 4.


    Here is the scenario
    1) Caller calls (runprogram wait, chain wait, shellexecute waitforsingleobject) callee
    2) Callee sends Info_Box, then wait a minute
    3) Callee exits/quits
    4) Caller sends Info_Box, then wait a minute
    5) Caller commits a find / reread / save

    If you do the above sequence, no more status 4. Taking out the Info_Boxes, then you get status 4.

    The "waiting" strategy is not a viable workaround because that will make the entire process insanely long. The current workaround (closing/reopening files) is much faster at this time. However it is puzzling as in why the caller runs into status 4, and why the workaround works in the first place.

    Thanks,

    Frank Cheng

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •