Choice List Loose value in disclosed af:Query (Fixed in 11.1.1.4)

Choice lists seem to be quite sensitive on loosing their value. Apart from popups with full submit button, they loose their values also inside af:query component when it is closed and submited.
In a simple Query page with Query panel and result table I put some criteria values:


Then i close the Search panel and i press Submit button


When i open Search panel again the selected value in department choise list is lost


Is this a nice bug or what?
Test Case:
http://adfbugs.googlecode.com/files/TestDisclosedCriteria.zip

Number precision and conversion in query criteria

There is a strange behavior of number type fields in af:query.
I created a simple Query page from HR schema for Employees (Entity and View) with some typical criteria.
When a user type a value in a String criterion field then he is not allowed to type more characters than the precision of the field.(i.e. 25 for LastName, email)
The same apply for the LOV field (Department 4 digits)
Yet Number fields have strange behavior.No mater the precision of the Number field you can type as many digits you want.
Yet if you type up to 21 then the last 4 digits are converted to 0!!?
If you type more than 21 digits it is converted to the first digits with other 3 as decimals!?
If you type number with more than 3 decimals it is rounded to 3 decimals.

These restrictions make large numbers not usable for query criteria.
Is this a bug to be fixed?
Test case:

http://adfbugs.googlecode.com/files/ViewCriteriaPrecision.zip

Choice list and LOV in query criteria bug (Fixed in 11.1.1.4)

We have a strange bug in our application.
When ever in query criteria we have choice list as first criterion and we have also input List of values in criteria then the input List of values does not return values.
When you open LOV and select a row the LOV closes automatically and value is not returned.

I managed to reproduce it in simple test case in HR schema with 1 choice list and 1 list of values:


The workaround is either not to use choice list as first criterion or not to have Input List of values field autosubmit = true.

Strange?

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

Making View Criteria Case Insensitive.

When you create view criteria you can easily set in each string criterion if it should be Case sensitive or not by checking or unchecking 'Ignore Case'.




Yet the default view criteria used in LOVs or criteria of fields added in advanced search are always Case Sensitive and you cannot declaratively change that.


I found a realy old post of Steve Muench for similar case in very old release of jdeveloper

http://www.oracle.com/technology/products/jdev/howtos/10g/dynamiccrit/index.html


and managed with little changes to apply it in latest release also:



Now all view criteria for string fields are case insensitive.


Note that this implementation will override any criterion you have set as Case Sensitive.
You can add this code to your base view object so that all view objects work like that.

test case:
http://adfbugs.googlecode.com/files/TestCaseInsensitive.zip

Single Row LOV in Query Criteria Bug (Fixed in 11.1.1.4)

When List of values has only 1 row then in query criteria you cannot set input to null after the first time you set a value.

To reproduce in the test case of Employees with Departments LOV i set where clause of DepartmentsView rownum=1.

I assign DepartmentsView as LOV in Employees.DepartmentId attribute and set it to autosubmit.

I put DepartmentId in query criteria of Employees.

I create a simple query panel with results table for Employees and i run application:


Steps to reproduce:
1. open DepartmentId LOV and select value. press tab or search
2. delete value of DepartmentId and press tab or search
Result: value is not deleted from LOV field. and search still has the criterion.

Only way to make value null is to press reset button.

Is this a bug?

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

Rollback to same row with view criteria workaround

Rollback for Forms and ADF means that we re-query data from database and remove changes that the user did.

From the user side of view rollback is expected to return to him to the same state he was when he last saved data.

So when the user that work on a Form (Row) presses Rollback and looses the row that he was working on is really confusing for him.

Fortunately Steve Muench has issued a workaround for this that many people use now in ADF applications.
http://blogs.oracle.com/smuenchadf/examples/
68. Restore Current Row After Rollback

Yet the above workaround does not work when View criteria are applied in view object and latest changes committed does not comply with these criteria.

This happens because Rollback forces query to re-execute with the applied view criteria and the changed (current) row does not exist in the new results set.

So for example in the current application there is a query and an edit page.
If you Query departments for specific manager (i.e. 100) and go to edit page if you change manager (i.e. to 200) and commit, after that if you press rollback you will loose that row since there is no longer in the queried rows.




I have applied a workaround in the current test case for that issue. In the beforeRollback of the view object I add a View criteria row that matches the current row primary key. This causes the current row always to comply to view criteria when we press rollback since in the query it is added
WHERE …. or (PK_FIELD = CURRENT_ROW_KEY)

In method afterRollback I remove the specific criteria row so that if the user query again (not by rollback) the results without the current row to be fetched.

This way the current row is not lost when it does not comply with applied criteria and we press rollback.

This workaround we have implemented in our Base ViewObjectImpl class and works also with composite primary keys.
The only issue is that with applied view criteria with no values the ‘or’ operator does not apply and only the current row remains in the result set after the rollback.

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

Bind Variable and View Criteria in view with range paging bug (Fixed in 11.1.1.4)

I managed to reproduce bug described in

http://adfbugs.blogspot.com/2010/01/new-bind-variable-and-view-criteria-bug.html

in a simple query page for view object with Range paging tuning.


When you query with a department then Reset and then Query again after scrolling and selecting rows, it throws exception:
java.sql.SQLException: Attempt to set a parameter name that does not occur in the SQL: inDeptId



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

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

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

Returning Multiple values from LOV in af:query with bind variables bug

We get nullPointerException when returning multiple values from LOV in view criteria with bind variables.

To reproduce it in EmployeesView for departmentId I added LOV that also return ManagerId.



It work fine for Forms (TestForm) and for tables(TestTable), but not for af:query with bind variables:

I created 2 view criteria with departmentId and ManagerId, 1 with bind variables and 1 with no bind variables. And 2 pages 1 for each
TestQuery1 with af:query with bind variables
TestQuery with af:query with no bind variables

When trying to select department in TestQuery1 we get:


Caused by: java.lang.NullPointerException
at oracle.adfinternal.view.faces.model.binding.FacesCtrlSearchBinding$AdfCriterionValues.(FacesCtrlSearchBinding.java:2834)
at oracle.adfinternal.view.faces.model.binding.FacesCtrlSearchBinding$AdfAttributeCriterion.(FacesCtrlSearchBinding.java:1732)
at oracle.adfinternal.view.faces.model.binding.FacesCtrlSearchBinding$AdfConjunctionCriterion._loadCriterionList(FacesCtrlSearchBinding.java:2775)
at oracle.adfinternal.view.faces.model.binding.FacesCtrlSearchBinding$AdfConjunctionCriterion._loadCriterionList(FacesCtrlSearchBinding.java:2725)
at oracle.adfinternal.view.faces.model.binding.FacesCtrlSearchBinding$AdfConjunctionCriterion.getCriterionList(FacesCtrlSearchBinding.java:2633)
at sun.reflect.GeneratedMethodAccessor840.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)

Yet TestQuery return correctly departmentId and ManagerId.

So I guess the workaround is not to use bind variables in view criteria.

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

Af:Query bind variable bug (Fixed in 11.1.1.3)

We have noticed in our application a bug that when we enter a page that has af:query with bind variable, after ExecuteWithParams, it always keeps the first value that we first entered the page.

I reproduced this bug in a simple Departments Employees Test case:

In Employees View object i have a query criteria for DepartmentId = :inDepId. In the taskflow that opens the Employees query page i first run ExecuteWithParams for the task flow input paramter.



When i run application in the main page i select a department and then i pass DepartmentId as input value to the Employees task flow.



The first time i call Employees task flow everything works fine. The value of input parameter is set in the criteria and Employees of that department are queried:



But when i return to departments and select an other department and go to Employees again, the bind Variable in Query criteria is still the same, Even though the input parameter and the results have changed for the new department.


Isn't this realy strange?

If i change value and press reset it allways return to the first value that af:query is executed.
I tried in bindings refresh conditions and TrackQueryPerformed="Page" with no luck.

Is this a bug?

Is there a workaround?

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

View Criteria with Exists Optional Bug

I created a simple HR application with departments and Employees

In DepartmentsView i put query criteria, wanting departments that have Employees with old hire date.

The issue is that i want if no criterion is entered to show all departments. I thought since exist criterion is optional it should work. But no, it show anyway only departments that have Employees.

I think The solution would be easy for oracle developers if for view criteria where clause, instead of:

( (EXISTS(SELECT 1 FROM EMPLOYEES Employees WHERE ( ( ( Employees.HIRE_DATE < :inBeforeDate ) OR ( :inBeforeDate IS NULL ) ) ) AND (Departments.DEPARTMENT_ID = Employees.DEPARTMENT_ID))) )

when the exists criterion is optional to set:

( (EXISTS(SELECT 1 FROM EMPLOYEES Employees WHERE ( ( ( Employees.HIRE_DATE < :inBeforeDate ) OR ( :inBeforeDate IS NULL ) ) ) AND (Departments.DEPARTMENT_ID = Employees.DEPARTMENT_ID))) OR ( :inBeforeDate IS NULL ))

test case :

http://adfbugs.googlecode.com/files/TestExistQuery.zip

Query Component Required Criterion bug 2

In the same application bellow as i said that bug does not happen all the time
Some times there is an other bug.
When you first enter the Query page there are no data, since it is not executed by default and no criterion is selected.
If you just navigate to the edit page (edit or new) and return then the result table is full of data.
Is this a bug?
Is there a workaround? Except than using different view object for query end edit

you can download testcase from
http://code.google.com/p/adfbugs/downloads/detail?name=TestQuery.zip&can=2&q=#makechanges

Query Component Required Criterion bug (new r1 Bug)

So I decided to upgrade my application.
I added List of values for Departments for EmployeesView.DepartmentId and Department name in Employees view. I also added DepartmentId in query criteria as required criterion

I also created an edit page for Employees and navigation between pages with default task flow.

So I run and go first again to the search page.
Before Release 1 of jdeveloper 11 when you had required criteria and press search without entering values, nothing happened. That was quite frustrating for users but we could explain it to them with the * sign.

Now a message is displayed explaining that. So I was happy to see it:

But after some searches and navigations to edit page and back. I was surprised to see that the layout was broken.

I could not navigate or do anything any more...
I check the console to see the following:

<05-jul-2009> <[ServletContext@5888435[app:TestQuery module:TestQuery-ViewController-context-root path:/TestQuery-ViewController-context-root spec-version:2.5]] Servlet failed with Exception oracle.jbo.AttrValException: JBO-27014: Attribute DepartmentId in EmployeesViewCriteria is required at oracle.jbo.rules.JboVCItemRequiredValidator.validateItem(JboVCItemRequiredValidator.java:90) at oracle.jbo.rules.JboVCItemRequiredValidator.validate(JboVCItemRequiredValidator.java:160) at oracle.jbo.common.ViewCriteriaImpl.validateRow(ViewCriteriaImpl.java:597) at oracle.jbo.common.ViewCriteriaImpl.validate(ViewCriteriaImpl.java:558) at oracle.jbo.server.ViewRowSetImpl.validateViewCriteria(ViewRowSetImpl.java:7152) Truncated. see log file for complete stacktrace >

So is this a bug?
Is there a workaround?

Query Component Focus bug

You can say that I am strange or whatever but imagine if users ask that query criteria should have focus when you enter the page...
I could say that its a detail... that its not so important...
But they will reply that every search engine in the world has initial focus. Imagine if in Google or youtube you should click in search field to search something...
So I try to do it.
There is a property in af:document for initialFocusId so I set it to Query component since I can't get inside.


But still I am many tabs away of focusing the first criterion.
So I tried to remove components above the criteria like:
No Match All – Any

remove save
put mode to footer
but I just managed to be 1 tab away from criteria


The only way I could do it is by using simple mode for Query component


So is this a bug?
Or should I chose between focus and advanced search?

Query Component Save bug

In the same application bellow i try the Save... button


Since i usally want to query employees with salary >3000 i set that value and i save search:


But when i run that saved search i dont get the result, the value of criterion is lost:


So i thought ok it doesn't save values, lets see advanced search:
I use advanced search and add Salary again with same value.
I save criteria and now it saves both criterion and value:

So it doesnt save criteria values that have bind variable.

Yet i wouldnt know how to explain this to an end user...

Is this a bug?

No? since it has a workaround?
Dont use bind variables in criteria?

Query Component validations bug

So I installed Jdeveloper 11.1.1.1.0 new release yesterday
I created Default Business Components from test HR schema
In the EmplyeesView I created View Criteria for 2 attributes:
HireDate and Salary

Finally I created a default search panel with result table.
So I run it and tried to use it
I am a bad user so I put wrong format for the HireDate and not a number for Salary
I press search and logically I had validation errors.
So I pressed reset thinking that it will clear the values to put new...
but still validations fire... no reset is executed

I thought I need to look at the manual. There must be a way to clear criteria when I have invalid values.... but no luck.
So is this a bug?
Is there a workaround?
If there is a workaround is this still a bug?
Will Oracle fix it?