Required Criterion on Choice List type Attribute.(Fixed in 11.1.1.3)

Trying to replace some inputListOfValues fieds that have small amount of data with choiseList components we fall into the following.

If the choice list attribute is used in view criteria as a required criterion then even if you select a value, validation error ‘Error: A value is required.’ Still shows up.


This happens even when attribute is set to autoSubmit.

Is this a bug?

We use input list of values instead as a workaround.

Test case:
http://adfbugs.googlecode.com/files/TestRequiredChoiseList.zip

Selectively required criteria in LOV (Fixed in 11.1.1.3)

In order to improve performance in LOVs I tried to set selectively required criteria, so that the query of LOV should always run with some parameters.
So in simple department LOV in employees.departmentId attribute I put view criteria with selectively required option.



Also as in test case :
http://adfbugs.blogspot.com/2009/08/lov-execute-query-many-times.html
I override the method executeQuery for collection and print the query:

@Override
protected void executeQueryForCollection(Object object, Object[] object2, int i) {
System.out.println("EmployeesLOV executes Query :" + this.getQuery());
super.executeQueryForCollection(object, object2, i);
}

When I run application and open LOV and select a value, in log I see that 3!? Queries are executed:

Query : SELECT Departments.DEPARTMENT_ID, Departments.DEPARTMENT_NAME, Departments.MANAGER_ID, Departments.LOCATION_ID FROM DEPARTMENTS Departments WHERE ( ( (UPPER(Departments.DEPARTMENT_NAME) LIKE UPPER( :vc_temp_1 '%') ) ) )
Query : SELECT Departments.DEPARTMENT_ID, Departments.DEPARTMENT_NAME, Departments.MANAGER_ID, Departments.LOCATION_ID FROM DEPARTMENTS Departments WHERE ( ( ( (UPPER(Departments.DEPARTMENT_NAME) LIKE UPPER( :vc_temp_1 '%') ) ) ) AND ( ( (Departments.DEPARTMENT_ID LIKE :vc_temp_2 ) ) AND ( ( (UPPER(Departments.DEPARTMENT_NAME) LIKE UPPER( :vc_temp_3 '%') ) ) ) ) )
Query : SELECT Departments.DEPARTMENT_ID, Departments.DEPARTMENT_NAME, Departments.MANAGER_ID, Departments.LOCATION_ID FROM DEPARTMENTS Departments

The Last query without any criteria !?

If I just type a valid value to the field and press tab then 4!? Queries are executed:

Query : SELECT Departments.DEPARTMENT_ID, Departments.DEPARTMENT_NAME, Departments.MANAGER_ID, Departments.LOCATION_ID FROM DEPARTMENTS Departments WHERE ( ( (Departments.DEPARTMENT_ID LIKE ( :vc_temp_1 '%') ) ) )
Query : SELECT Departments.DEPARTMENT_ID, Departments.DEPARTMENT_NAME, Departments.MANAGER_ID, Departments.LOCATION_ID FROM DEPARTMENTS Departments WHERE (Departments.DEPARTMENT_ID = :fbkKy__0)
Query : SELECT Departments.DEPARTMENT_ID, Departments.DEPARTMENT_NAME, Departments.MANAGER_ID, Departments.LOCATION_ID FROM DEPARTMENTS Departments WHERE ( ( (Departments.DEPARTMENT_ID LIKE :vc_temp_1 ) ) AND ( ( (UPPER(Departments.DEPARTMENT_NAME) LIKE UPPER( :vc_temp_2 '%') ) ) ) )
Query : SELECT Departments.DEPARTMENT_ID, Departments.DEPARTMENT_NAME, Departments.MANAGER_ID, Departments.LOCATION_ID FROM DEPARTMENTS Departments

The Last query again without any criteria !?

So you don’t gain much in performance of LOV since the query is executed many times again and without any criteria.

Also sometimes when you just type a value, you get the PPR exception, or an invalid value exception even if the value is valid.

Steps to reproduce:
1. Run TestLOV page
2. open department LOV, type A in DepartmentName criterion and press search
3. Without selecting a row press OK or cancel.
4. Type a valid value to LOV (i.e. 50) invalid value message appear.


5. Open LOV again, press OK or cancel then press submit button



oracle.jbo.AttrValException: JBO-27036: At least one of the following attributes DepartmentName, ManagerId is required. at oracle.jbo.rules.JboVCItemRequiredValidator.validate(JboVCItemRequiredValidator.java:172) at oracle.jbo.common.ViewCriteriaImpl.validateRow(ViewCriteriaImpl.java:606)

It seems that Selectively required criteria in LOV has some issues.

Test Case :
http://adfbugs.googlecode.com/files/TestLovSelectivelyRequired.zip

New Bind Variable and View Criteria bug

In the last patch of jdeveloper (1.1.1.2.0) there are a lot of improvements and bug fixes in view criteria functionality.

1 of the bug fixes is the performance of view criteria that had optional bind variables.

For example if in the Employees View you had optional criterion for departmentId with bind variable ‘inDeptId’ then in the query of the view object with applied view criteria in the where clause it was added ( (Employees.DEPARTMENT_ID = :inDeptId ) or :inDeptId is null )

Yet this adds a large execution time when inDeptId was null since it is forcing a full table scan.

After the last patch when you define optional criterion for departmentId with bind variable ‘inDeptId’ the where added is (Employees.DEPARTMENT_ID = :inDeptId ) and the optional part is implemented by removing the where clause expression.



Yet this dynamic change of query depending on parameters values sometimes throw exception:
(java.sql.SQLException) Missing IN or OUT parameter at index:: 1

I manage to reproduce it in a simple test case in Application Module Browser.

Steps to reproduce:
1. Open EmployeesView1
2. Press Search button (Specify View Criteria)
3. Select EmployeesViewCriteria and press find
4. set departmentId = 10 and press ok
5. Repeat 2-4 but set departmentId = null (empty)

The following exception appears.



If you create a simple search page with query panel and results table then you can’t reproduce this. It is reproduced in our application when we programmatically change view criteria values and execute, but I can’t identify specific conditions

Is this a bug?

Anyone else has run into this?

Test Case
http://adfbugs.googlecode.com/files/TestNewBindVariable.zip

Happy New Year

2009 was my first year of posting in this blog and I must say that I really enjoyed it.
Mostly because of the fact that you read this and you post constructive comments.

I will continue to post defects this year also, even though interesting defects are getting harder to find.

That is actually a good thing. May be I will upgrade this blog to also post defects that developers use to create.

Any other ideas are welcome.

Happy new year to everyone