I found it!
The procedure to find something like this is:
copy form to a throwaway copy.
create another unused block with one item.
copy each form and block trigger to the unused block. Test. If it still fails, remove another one.
If that doesn't do it,
then do the same thing removing sections of items until you find the section with the bad item.
So it was code in post-query block trigger, code like this:
if :DATA.MYCODE1 is not null then
select max(explanation) into :DATA.MYEXPL1 from code_table where code = :DATA.MYCODE1;
So it was retrieving a code explanation and putting it into a non-database display field on the form
(a field that accidentally was not big enough).
It needs to be a lot easier to find problems like this. And in cases like this it should just give a warning it is
truncating the value instead of just totally bombing retrieving the record.
There are two possibilities for this error (except from the one that there really is not data found):
1. YOu have an item which only accepts specfific values (checkbox, radio-button, poplist) and none of the values of the item matches the db-value for a record
2. Your POST-QUERY ends with an exception (which it was in your case)
What i usually do is:
1. Remove the POST-QUERY-trigger and try again. If the error is gone, check the POST-QUERY in mor detail
2. Remove the poplist, checkbox and readio-button-items and try again.
Still work to be done, but its quite fast to find the reason.
You were so right!
I would really like to see forms do more to save us from ourselves accidentally creating run-time errors. It is ever so easy to create a form with a size or type mismatch between the form and the database either with an original error or an
error created later such as increasing the size of something in the database. So that suddenly one day the mismatch causes the form to fail.
I'm suggesting something like the form compiler to produce a sort of spreadsheet of the form like
form block type name mapping_other db_column db_column_type db_column_size checked/radio_value unchecked_value
With radio groups it is essential to include the radio group name with radio_buttons!
So it would analyze those pesky radio buttons and checkboxes but further also analyze sql and show what fields in
what tables are being sent to what items or variables. I'd have to think more about this...
form block trigger_type trigger_name block item type max_size db_table db_column db_type db_column_size plsql_variable