Thursday Jul 05, 2012

Bind Variable and SQL error during statement preparation

 I was getting the following exception at run-time.

JBO-27122: SQL error during statement preparation. Statement: SELECT AxEO.A_ID, AxEO.B_ID, AxEO.C_ID, ByEO.A_ID, ByEO.B_ID, ByEO.C_ID, Cz.A_ID, Cz.B_ID, Cz.C_ID FROM ABC_x AxEO, ABC_y ByEO, ABC_z CzEO WHERE AxEO.A_ID = ByEO.A_ID AND  CzEO.A_ID = :Bind_PId

I copied and pasted the query on SQL worksheet, replaced :Bind_PId with a valid id, and executed the query. The query worked alright, implying the query was alright. I tried to connect to different DBs but the issue persisted, meaning it was not a DB issue either.

Finally, the root cause was found to be in the concerned VO; one of the bind variables (say Bind_TId) was marked "Required". De-selecting the Required check-box resolved the issue.

In retrospect, the issue looks to be rather straight-forward. However, the error message is not very helpful, if not misleading. Besides, it's counter-intuitive to think that a bind variable which is not being used in a query can cause error while statement preparation. The other bind variable - Bind_TId - was being used in other view criteria, not the view criteria involved in the given query. Still, it was required.

Monday Jun 25, 2012

View Link inConsistency

What is View Link Consistency?

When multiple instances (say VO1, VO2, VO3 etc) of an EO-based VO are based on the same underlying EO, a new row created in one of these VO instances (say VO1)can be automatically added (without re-query) to the row sets of the others (VO2, VO3 etc ). This capability is known as the view link consistency. This feature works for any VO for which it is enabled, regardless of whether they are involved in a view link or not.

What causes View Link inConsistency?

View Link Consistency for a VO could be disabled by disabling jbo.viewlink.consistent for the VO (or globally), or by applying setAssociationConsistent(false). Otherwise, any of the following can cause View Link inConsistency. 

1. setWhereClause

2. Unreferenced secondary EO

3. findByViewCriteria()

4. Using view link accessor row set

Why does this happen - View Link inConsistency? Well, there can be one of the following reasons.

a. In case of 1 & 2, the view link consistency flag is disabled on that view object.

b. As far as 3 is concerned, findByViewCriteria is used to retrieve a new row set to process programmatically without changing the contents of the default row set. In this case, unlike previous cases, the view link consistency flag is not disabled, meaning that the changes in the default row set would be reflected in the new row set. 

However, the opposite doesn't hold true. For instance, if a row is deleted from this new row set, the corresponding row in the default row set does not get deleted. In one of my features, which involved deletion of row(s), I observed that my changes were not reflected on UI. To resolve this apparent "view link inconsistency" issue, I replaced findByViewCriteria by applyViewCriteria.

b. For 4, it's similar to 3 - whenever a view link accessor row set is retrieved, a new row set is created.

Now, creating new row set does not mean re-executing the query each time, only creating a new instance of a RowSet object with its default iterator reset to the "slot" before the first row. Also, please note that this new row set always originates from an internally created view object instance, not one you that added to the data model. This internal view object instance is created as needed and added with a system-defined name to the root application module.

Anyway, the very reason a distinct, internally-created view object instance is used is to guarantee that it remains unaffected by developer-related changes to their own view objects instances in the data model.

About

ADF Tips and Tricks

Search

Categories
Archives
« July 2015
SunMonTueWedThuFriSat
   
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
 
       
Today