PITSS Tech BlogNews zu Java, PL/SQL, Entwicklung & Technologiewechsel
Forms 188.8.131.52 Insert into View ends up with FRM-93652
After upgrading your Forms Application to 184.108.40.206 you may run into a problem, that in the INSERT-Statement (probably for UPDATE as well) the Forms runtime crash and ends up with an FRM-93652.
In the support.oracle.com you’ll find a couple of entries to this, especially the Note Doc ID 2219520.1, which exactly describe the behaviour. This Bug should be fixed in 220.127.116.11, but in our environment seems to be back in 18.104.22.168.
In our scenario we had a database block in forms, running on a view with an instead-of trigger behind, doing a POST-Statement to validate the data inside the database and the record manager is asked to use the default properties:
KEY_MODE = AUTOMATIC
ENFORCE_PRIMARY_KEY = NO
Letting the record manager using the ROWID-Concept failed in this case. The view inside the database is updateable and a testcase on the same database with an older Forms Version run fine.
The only possibility so far, is to change the default behaviour of the record manager and decide per definition, which columns/items should be used as primary key. So we have to change:
KEY_MODE = NON_UPDATEABLE/UPDATEABLE (depending of the fact, if you want to update the primary keys during the update statement of the block)
ENFORCE_PRIMARY_KEY = NO (during the fact, that in the case of the INSERT Statement the INSTEAD_OF Trigger calculate the Primary Key, the record manager could not ensure during the POST to avoid uniqueness.
PRIMARY_KEY = YES (for each Column/Item inside the block, which is part of the Primary-Key-Constraint)
For letting a block based on a view, with which the record manager has his problem to use the ROWID concept, this configuration is in any case good practise.
We running a ticket in Oracle support and update this note, as soon as we get feedback from Oracle.