APEX Error 572 autopsy

A couple of days ago I exported an application from APEX 24.1.5 and imported it into APEX 24.2.9 on my OCI free tier instance.

Whilst the application itself was working fine, I got a problem when I tried to edit page 4 in the App Builder: the spinner kept spinning for an unusual amount of time and eventually stopped showing an empty page, and in the error notification area APEX showed "Error: 572".

 

Now, according to other users this Error 572 was a symptom of an overloaded database, which seemed strange to me because the page is not particularly complex and I could open other pages in the editor without problems.

After various unsuccessful attempts to see if I could gather some meaningful information from the APEX Builder debug logs (see this interesting Steve Muench's blog posting on how to do that), I decided to have a closer look at the differences between the previous version of this page and the current, problematic one.

Here are some relevant facts:

• The current version of the page can be edited without problems in APEX 24.1.5.
• If I export this single page from 24.1.5 and import into 24.2.9 the problem persists, so if there is a problem, it's not caused by the import process of the whole application.
• The "new" version of the page works correctly when I run the application, so, APEX metadata must be good.
• The only difference between the old version and the new version is in the source of the query I am using to populate an Interactive Report.
• If I import the old version of the page, then the App Builder editor resumes working properly. 

The difference between the old and the new query is the following CASE function, the old version did not contain the lines in yellow: 

case 
  when json_value(e.value,'$.email[0]') is null
  then apex_lang.message('NO_RECIPIENT')
  when json_value(e.value,'$.email[1]') is null
  then apex_lang.message('SINGLE_RECIPIENT')
  else apex_lang.message('OTHER_RECIPIENTS')
end as RECIPIENTS

If I comment out the two lines in yellow in the page source, import the page and try to edit it, everything is back to normal.

The tricky part in this type of problems is in that if you receive this error upon entering the editor then you cannot delete the offending page because Error code 572 is breaking the delete page functionality, so your only option is to replace the page with an import of a working version.

If you receive this error while you are still inside the editor of the page, you may have a chance of reverting the page to its previous state.

In my case it was easy, I had an older working version of the page, but if you don't, then you must work around the problem in some other fashion, in the worst case I presume you must edit the import file and get rid of some components.

In conclusion, my wild guess is that something wrong is happening at parse time and in particular I strongly suspect that the absence of meaningful values for the bind variables used in the conditions of my query are breaking the logic of the JSON_VALUE function that relies on the content of the JSON array "email", which at parse time of course is empty, resulting in this weird error.

Moreover, the IR query handling must have changed in some way between the two APEX releases.

Now, it could be that Error 572 is also returned when there is a "database overload", but in this specific case I can't see any correlation.

Or may be there is something else going on that I can't fathom right now.

Tip of the day: hide (or show) multiple buttons or other page components with a single dynamic action

Need to hide or show multiple buttons or page items basing on a common client-side condition?

Instead  of creating a single dynamic action for each button, define a common CSS class (i.e. mybuttons) on each of the buttons and then use a single DA with jQuery selector like ".mybuttons" for the Hide action and one for the Show action, thus reducing the page complexity.

 

And you can also extend this to other components like page items or regions, if they follow the same logic.

Oracle APEX, OCI, Ollama at work thanks to OllAPEX for the #JoelKallmanDay

Today is the day dedicated to the late Joel Kallman, a mentor and friend, so I thought it would be nice to show off my APEX application hosted on OCI working with LLMs run via the Ollama server located at home.

It's an interesting exercise because one learns a lot about how these "things" work, the strong and weak points of each model, which one works best for a certain task, which one has the best "vision" capability, which one creates the best embeddings.

So, here are a few short videos showing some "vibe" coding that I'll need to revise tomorrow, the analysis of two versions of the same procedure created by the same LLM, then a "live" comparison showing how other models answer the same question differently.

So far, so good.

#JoelKallmanDay #orclAPEX, #AI