This is a first for me. A much-used procedure which suddenly would not compile after its file opened. When run, it came up with a compile error (“this procedure cannot be used: it contains one or more incorrect steps”).
When the procedure window was opened and the check procedure button was clicked, it compiled and thereafter ran normally.
I cannot remember this one appearing in QNA or the current forum and can find nothing. I would dearly like to prevent this happening again.
I have a copy of the file in which this behaviour is reproducible.
It sounds like the compiled code was somehow corrupted. Clicking the check procedure button recompiled it from the source code, and corrected the problem.
Procedures don’t recompile every time you run them, so the problem wasn’t that it couldn’t compile. It hadn’t even tried to compile it. Some of the compiled code just didn’t make sense to it.
This occurred the same day I had released a new version of the file containing the procedure to four locations and it happened in all four when the procedure was used (it’s only used once per day). Do you reckon it could have been compiled and then corrupted in all four locations?
I’ve never seen this behaviour before even once, let alone four times.
I think it was compiled and then corrupted at your location, possibly when you saved it after making the changes. The corruption was there when it was distributed. If that procedure wasn’t one of the changes, it might have been compiled days, weeks, months or years before it was corrupted.
It is compiled when you error check. It is also compiled when you close the procedure window, leave the procedure window or save with the procedure window active, after making changes to the code. If your users can’t or don’t open the procedure window, it will not be compiled while they are using it.
I have noticed that if I use the “View Wizard” to search the procedures, and then open a Procedure from the “View Wizard”, then, if I don’t explicitly “Check Procedure” (the “checkmark” icon) before saving and closing the database, that procedure will fail the next time the database is opened.
If I then open that procedure, click the “Check Procedure” button, and re-save and close, all is well again.
My question: is there a way to list all procedures that are in the “opened” state so that I can know that all my procedures have been compiled correctly?
I just tried the exact steps you described, but I wasn’t able to to duplicate this behavior. I didn’t think I would be able to duplicate this problem, because I use the View wizard all the time to open procedures, but I did go ahead and try specifically to duplicate this.
When you say “that procedure will fail”, do you see an error message saying “this procedure has one or more incorrect steps”? or is it some other kind of failure?
Both Panorama 6 and X will recompile a procedure if any of the following events occurs:
The Check Procedure button is clicked.
The database is saved.
The procedure window loses focus for any reason – another window is opened or clicked on, or the procedure window is closed.
Basically, the only way that you can get Panorama to not compile changes to a procedure is to crash Panorama – pull the plug on the computer or force quit Panorama (or, obviously, if Panorama crashes for any other reason).
Yes, the error is: “This procedure has one or more incorrect steps”
The place I see this happen is with “shared” databases. (I just tried it on a non-shared db, and it works as you outlined).
When I get a moment, I’ll explicitly try with a “shared” database. I’ve just gotten into the habit of explicitly clicking the “Check Procedure” button and saving when I work on a procedure and I have not seen the error again.
Is there a Panorama function or procedure that lets me programmatically “check” a procedure?
I have a lot of functions in a given database, and I’d like to have a procedure that walks all the other procedures in the DB and execute a “check procedure” on each one as a way of ensuring they’ve all been “compiled”.
In Panorama X this is trivial with the getprocedureoption( function.
In Panorama 6 it is a bit trickier, but I believe possible. What you need to do is extract the text of the procedure into a variable using the getproceduretext( function. Then you can use the execute statement to check it. But since you don’t actually want to run the procedure, you can add "rtn " to the beginning of the source code so it will just get checked but not run. For example:
local pcode
pcode = getproceduretext("","Some Procedure")
execute "rtn "+pcode
if error
... this code has an error
message info("executeerrorsource") // display the problem code
endif
Hmm … ok, that looks like some of the documentation I’ve read.
What I really need to accomplish is ensure that Panorama correctly “compiles” the procedures when the database is closed.
Here are the steps that sometimes, but not always, leads to an error:
Open a shared database (seems to have to be shared)
Open a procedure
Note: the Panorama “status bar” says, “Procedure opened”
Quit Panorama
Launch Panorama and re-open the database
Attempt to execute the procedure that had been opened from the “Action” menu
Sometime, this leads to a “this procedure cannot be used: it contains one or more incorrect steps” error dialog, but not always.
If, at this point, the procedure is opened, and the “Check Procedure” button is clicked (so that the “Panorama status” says, “Procedure OK.”), then the procedure works as it should and no error occurs, even after Panorama is quit and re-launched.
I would just like a way to ensure that all “open/uncompiled” procedures are compiled and saved so that they always work when the database is opened up.
Or, maybe it’s just me … and my network has “dirty bits” flying over it!
I don’t know how the steps you outlined could lead to an error. Panorama always compiles the code whenever a procedure window is deactivated. This includes clicking on another window, closing the window, or quitting the application (which of course closes all windows). In other words, Panorama performs the Check Procedure operation any time a procedure window loses focus. It also automatically compiles when you save the database. The only reason for the Check Procedure tool is to allow you to perform the check without switching away from the window.
Internally, the only difference between a shared database and a single user is that Panorama runs some additional code when opening the database to set up the connection with the server, and some additional code when closing the database to tear down the connection. Also a bit of extra code is run when starting and finishing editing of a cell. Otherwise, a single user and shared database is the same. There is no difference in how procedure code is set up or handled internally. In fact, that is kind of a bummer, it would be nice if procedures could synchronize like data does.
Bottom line, Panorama is already supposed to do this for you. Since I know you are an experienced programmer, I’ll tell you that the compilation code is being called from the window deactivation handler, so I don’t see how the window could ever close without also compiling, and I have never seen it do so.
Thanks for the detailed explanation – and, that is how I imagined it worked.
Is there some callback/trigger code that I might have that inadvertently has the side effect of aborting the compilation? (Yeah, I know, that sounds far-fetched … grasping at straws here. )
