A user had several crashes in a row yesterday in the same unshared database that I have reported earlier. I continue to search for ways to avoid them. I think, but am not certain, they occur when the first assignment statement in a procedure is reached. Yesterday, the assignment came immediately after an addrecord statement. (The procedure adds a record and proceeds to assign values to several fields.) I wondered if this could be similar to the problem of opensecret followed by a variable definition, where it appears to me that one statement has not completed before the next line of code is executed. (Earlier I was suspicious that there was some connection between a find statement followed by an assignment, but never proved that nor ruled it out.)
In the addrecord / assignment case, it has worked hundreds of times, but then seems to fail several times in a row. On at least two occasions, I had added console statements to try to diagnose where the crash was occurring, and the crashing stopped after the addition of the console statements surrounding the assignment.
So I thought intentionally introducing a delay after the first addrecord statement, which I am going to do with the code that I posted in the PanX feed a few minutes ago, might eliminate the crashes. Do you have any reaction to my idea?
BTW, I assume the smallest delay I can create with a timer is 1 second, i.e. no fractional seconds.
It’s a shot in the dark. Won’t hurt anything if done correctly.
How much code is after the pause? By using pause this way, you’re adding a new unknown to the equation. I think I would not use pause for this, but use one of the techniques I mentioned in my other post. That might be significantly more work for you, but if some new problem is added by using pause/resume we will have a hard time disentangling which problem is which. You’ve given me some ideas though on the possibility of making a simple pausefordelay statement.
You can actually set it to zero. You might think that would be pointless, but it isn’t. This pushes the code out of the current run loop. In other words, Panorama will get a chance to finish up everything else it is doing before continuing with this code.
The thing is, there essentially should already be a pause like this built into add record, assignment, etc. as Panorama needs to wait for the server to respond. But maybe there is some problem there that I haven’t been able to track down. Perhaps it only happens if someone else performs a server action at the exact same moment. I’m speculating.
Using tickcount is a whole different kettle of fish. In that case, the code simply continues to operated in the current run loop. Time passes, but other code gets no chance to run. So tickcount definitely isn’t going to be helpful in this situation, all it does is make the same thing happen slower.
I’m sorry for my use of the technical term “run loop”, but it’s needed to precisely express what is going on in this situation. If you want more info on this, you may find the “Anatomy of a Run Loop” section of this page enlightening. Or you may just find it TMI.
To be clear, you’re running that 310 lines in the timer no matter what you do, including with your pause solution. However, putting that much code in the code parameter is awkward because then you don’t get any compile time checks for Panorama, if you make a typo Panorama won’t catch it.
I would suggest something like this.
starttimer ...,"CODE",{farcallwithin "mydatabase","myprocedure","finishup"},...
return
finishup:
// rest of the 310 lines of code goes here