So after a couple thousand successful runs, I get a missing operands error message. I have no idea what this is or how to deal with it. It does not say what is missing or which line is defective.
This is a disaster for me. I don’t have time to hit the books. I changed NOTHING in the listed procedures. And of course, nothing in the Error “Wizard” is copyable. Really not helpful bug detection, especially when AFAIK I changed nothing from what has worked semi-flawlessly for many months.
Someone may be able to help, but we’ll have to see the code involved.
Make a copy of the problem version then try reverting to a version when things were working. If that works something DID change. You could compare the codes to find what changed. Or you could just import the current (with problem) data into the older working version and trash the problem, unexplained.
I was able to duplicate this error message, and the Error Wizard showed the exact code where the problem occurred. Since you cropped your screen shot so tightly, we can’t see what the code section of the window shows.
In any case, the message indicates that you are using the execute statement.
This statement allows code to be assembled and run on-the-fly. By definition and design, this means the code potentially changes EVERY TIME the program runs.
The execute statement is very powerful, but it can also be very tricky. It’s best to use this rarely, only when absolutely necessary. In fact, most Panorama programmers will never use this statement at all. Since the code is being generated on-the-fly, it doesn’t actually exist anywhere permanently. This means it is very difficult for Panorama to to display an exact error message. On the other hand, you should be able to click the blue arrow (under “Open”) and jump directly to the execute statement causing the problem. This at least gives you a good clue where to look. Of course the solution may not be obvious on quick inspection, since the problem code isn’t visible in the editor because it is being edited on the fly. One trick I like to use is to temporarily replace the execute statement with a message or displaydata statement. That let’s me see exactly what code is trying to run.
If for some reason clicking on the blue arrow in the Error Wizard doesn’t lead you to the execute statement, you can use the View>Open View dialog to search for the word execute in your code. See “Searching Full Source” on this help page.
A final note – Panorama has a full featured programming environment that allows you to write complex programs. Complex programs can and often do have bugs. So far, there is no programming language ever invented that can prevent programmers from writing programs with bugs in them, and no such tool is on the horizon.
This is the code I got from Jim last fall (?) that has worked fine for my purposes. And it works without a problem in another similar DB. I haven’t changed it. All I can guess is something it is trying to operate on got changed, and of course we tinkers are always “improving” things.
The shown code contains a single executable statement only: downrecord. The other part of the code is a function, and this code does not say what to do with the resulting value.
It contains two executable statements. The first is execute. It looks like it thinks downrecord is a field or variable in its formula, and there should be an operator between it and the arrayfilter( function. Now we just need to figure out why.
Edit: It looks like downrecord is a red herring. It doesn’t seem to be any part of the problem.
I think both import() functions need to be chevronquoted(import()). One of your fields probably has a space in its name, and Panorama thinks it is two field or variable names which should have an operator between them.