LOV view criteria missing in af:query field when AM pooling is disabled

Question

Hi all,
Again, another strange behaviour with fields in af:query when AM pooling is disabled.
I have a field with a LOV in the af:query area. This LOV has a view criteria that involves a bind variable. In the VO, the view accessor for this LOV applies the view criteria and sets the bind variable. When AM pooling is disabled, double clicking a row or clicking the OK button in the LOV window removes the where clause defined by the view criteria. When activation occurs, the bind variable still exists but the framework doesn't know where to apply it...
Any help will be very appreciated,
Thanks
JDeveloper 11.1.1.3.0 with ADF BC
We've just realised that this behaviour occurs even when pooling is enabled. So this is becoming now a serious problem.
The scenario is as following: We have two LOVs in the search area (af:query). One of them is dependent on the other. Then, this second LOV has a view criteria and a bind variable representing the value selected for the first LOV. The query for the second LOV is filtered properly, but once a value has been selected and the LOV window dismissed, nothing is returned to the field.
We have observed that SecondLovViewImpl.executeQueryForCollection() method executes twice:
1. When LOV is opened: here, the bind variable is correctly setted.
2. When a row in the LOV table is selected: here, the bind variable is reset to null.
The log says (in Spanish):
<OracleSQLBuilderImpl><bindParamValue> [46062] Binding null of type 12 for "bindProgram"
<FacesCtrlLOVBinding$ListOfValuesModelImpl><_getRowFromSelectedRowKey> ADFv: No se ha encontrado ninguna fila para rowKey: [oracle.jbo.Key[P1 SP11 ]].
I would be very grateful if somebody asked me... even for saying "this is nonsense", "this is a known bug", "cascading LOVs are not supported by af:query", or anything else... If a code snippet is required, I'll put it as well.
Thanks in advance
Edited by: Marge on 02-sep-2010 5:41

Answer 1

Hi,
there are two bugs associated with bind variables in successors that I am aware of. One of them is supposed to be fixed in the next patch set, another one is still open. However, both problems were found with AM pooling enabled as well, so I don't know this is the same problem (though it sounds like). If you can, I suggest to create a reproducible testcase on one of the Oracle database schema, like HR or OE, and file a bug. If you don't have a time for or access to support, send the test case in a zip file (rename ".zip" to ".unzip") to the mail Id you find in my OTN profile. However, be aware that when I file the bug then it wont be visible for you, nor can it be escalated on your behalf. Anyway, at least it would get filed
Frank