PL/SQL update not working against 9iR2 DB

Question

Hi,
I am having a weird problem with several forms when run against a 9iR2 database. I have worked out that the problem only happens when referencing an unbound item in the WHERE clause of the update clause. For example:
UPDATE table_a
SET column_a = 'A value'
WHERE column_b = :block.unbound_item;
When I generate forms from Designer with this type of PL/SQL in a when-button-pressed trigger, it works fine against an 8.1.7 DB but does not update the record against a 9iR2 DB. If I put a specific value in the WHERE clause instead of referencing the unbound item, then it works. It also works if I put the value of the unbound item in a variable and then use the variable in the WHERE clause.
If I create a simple form using Form Builder, which does not link to Headstart libraries, then it does work against a 9iR2 DB. I also tried generating a simple form out of Designer from a container not linked to Headstart libraries and that worked as well.
Has anyone come across this sort of thing before?
Thanks.
Pierre.

Answer 1

Pierre,
I have heard from another customer that had a similar problem. I have not had time yet to investigate his solution, but maybe it can help you:
For the other customer it seems to work fine if the update raises a CAPI error, but it does not work if the update raises a server error or a TAPI error (PK/UK/FK violation). The problem is that the rollback in abort_transaction is not executed.
The other customer proposes the following solution:
* in abort_transaction, don't clean up the error messages
* in the exception handler of the button code, place the abort_transaction before the unhandled_exception.
Pierre, do you also use CDM RuleFrame? Can you try if the tips of the other customer work for you?
It sounds to me like this is a workaround for a database bug, which is OK, but it's better if the database bug is fixed. I would advise you to also check the available patches for 9iR2, or maybe report a bug yourself so a patch can be made in the future.
It may also be related to the optimizer mode. See thread Transactions fail when OPTIMIZER_MODE=choose .
Hope this helps,
Sandra Muller