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
Re: Status 4 errors with a weird fix
It's probably not related but it reminds me of this long thread
[URL]https://support.dataaccess.com/Forums/archive/index.php?t-40248.html[/URL]
and the manipulation of the floating point control value
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
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
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
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