I ran into this griefer and want to share the solution, as a reminder to check the obvious-but-not-so-obvious options in situations of unexpected behavior. Particularly on legacy code.

Working in a ooooold app – born in HTML days and lovingly upgrading through the years, on a legacy Data Upload page, I found that a validation on the column mapping page stopped working this year.

By “stopped working” I mean that the validation failed, but control never returned to the page. The error was logged appropriately, then the processing icon appeared and kept turning … the page hung. What!? This worked fine last year. Has been working fine since 2009. In the meantime we had upgraded (since all worked fine last year) to APEX 23.1. Did tons of tesitng, all should still be OK. (But did we test a failed column mapping? Hmm… this is a small part of a very large app …did we?).

Of course I focused on the validation. The visible thing making the noise. Tried all kinds of things I will not list here but will admit too, because, that’s what we do, we focus on the thing that is failing. We think.

Long story short, the issue was not the validation – it was doing its job (as I confirmed several times over). It was the Page: Reload On Submit setting.

It was set to Only for Success – a setting we use for editable Interactive Grids, and on more modern pages, as opposed to Always – which it needs to be for a standard legacy transactional page with On-Submit validations, so those validation errors will display atop the page, and sit there, on validation failure.

I was so focused on the validation, I missed the real issue: The Page was not behaving properly after a validation failure. I had to take a step back and look at the real issue.

Hard to do when in a crunch, or overtired, or working on a production issue that holding up a deadline, or all of the above.

Lesson learned: Take a step back. Walk away, come back. Get another set of eyes. Look at the real issue. Again.

How or why this setting was changed, I do not know and do not (almost really) care. Indeed all 3 pages ( we have 3 legacy Data Loads) had to have the Page Reload On Submit reset to Always. Was this from the upgrade? Most likley. Failed column mappings added to the testing list.

All is now good. Back to normal operations, many brain cells released to focus on normal work and moving forward

Aside: Why a keep legacy Data Upload? For the luxury of colum mappings, a very handy feature when one needs to accept different format incoming data files that all map into a standard set of column names. So far, there is no updated declarative data load option that has the column mapping interface that our end users use once a year and are used to. Could we write one? Yes. Given time and resources and priority. So it stands, for now. Remember that “legacy” does not mean no longer valuable. It does mean we may need to rewrite this whole thing at some undetermined point in the future. It means we need to do a lot of testing on every upgrade, as usual. I do hope that the APEX team simply forgets to remove this piece of legacy code.

Hope this helps someone else,

Happy coding,

Karen