Get_num_value return no data found with headstart 6.5.2.3

Question

Hi,
We are migrating an application based on headstart (capi generator 6.0.2.1). Our migration upgrade headstart to 6.5.2.3 (capi generator 6.5.3.4).
The capi generator 6.5.3.4 generate the get_row function, but this function doesn't call the find_on_stack function. With the old version of headstart, the get_row call find_on_stack. On another project I did for another company, I see that the capi generator 6.5.2 generate the get_row and this function call the find_on_stack.
The capi generator change after the version 6.5.2. I search on this forum and I see this "2227746 - ENHANCE RULEFRAME PERFORMANCE BY MINIMIZING CAPI USE OF FIND_ON_STACK" !
Our application has business rules that call get_num_value, get_char_value, etc... These get_???_value call get_row and get_row call slct function of the tapi.
Before the migration, these get_???_value functions returned always a row. Because the get_row scans the pl/sql table with the find_on_stack function.
Now, these get_???_value functions return the error no data found !!!. The function doesn't call the find_on_stack, but call the slct function of the tapi. The slct returns no data found.
I have this bug (no data found) when a business rule is executed from a delete cascade. The parent row is not there and the br returns no data found. The old version search the parent row with the find_on_stack and returns the row.
So, I suppose that the "ENHANCE 2227746" drop too much find_on_stack call !
Do you have a patch for this or I modify the capi generator ?
Thanks.

Answer 1

Geert,
The workaround mentioned above is not sufficient. It makes sure the correct value is returned inside a single transaction, e.g. when a transaction is rolled back, but when a new transaction is opened, it will still return the cached values, even though the database value might have changed between the closing of the first and the opening of the new transaction.
To make sure the correct value is returned, we should also keep track of the id of the transaction in which the cached values are stored. Only when this ID is the same as the ID of the current transaction, we can be sure the cached value is the correct one. In all other cases the database value must be used.
The following changes can be implemented as a workaround:
In the CAPI generator package HSU_CAPF:
- In procedure create_declarations add declarations of package variables to store transaction id for the cached values g_current_row and g_cached_row.
- In procedure create_init fill the transaction id when g_current_row is filled.
- In procedure create_get_row:
- Enclose if-statement as mentioned above, to make sure correct value is returned after transaction is closed      
- Add extra restriction to the if-statements to determine whether package variables can be used
- remove part to use value from CAPI stack      
- fill transaction id when g_cached_row is filled.
This solution slows down the retrieval of data via the get_% functions. It only uses cached values when they are cached in the same transaction as they are retrieved in.
Hope this helps,
Harold Oortwijn