Need Help with CommandLink Passing rowKeyStr to 2nd JSPX Page

Question

I've been working about 8 hours on something that should be simple - I have a databable displaying rows of data with a simple command link on one of the columns that will send the user to a 2nd page with a single record form showing detailed information for the selected row.
The problems I'm having:
* When I press the commandlink I do not get the correct record on the 2nd page
* Also I'm receiving the following error: JBO-25020: View row of key oracle.jbo.Key[11 ] not found in SearchViewIterator
When I use the af:tableselectone (selection) button to select the row first and then click the commandlink, the 2nd page DOES display the correct row, however I still receive the 25020 error above.
Note I am using the same View Object and Iterator for both pages.
I have compared my code against the SRDemo application and cannot see any differences - I was hoping someone could review my steps to see if I'm missing something (using JSF and ADF BC 10.1.3):
Page 1 JSPX Code Snippet (commandLink / ActionListener):
<af:commandLink actionListener="#{bindings.setCurrentRowWithKey.execute}"
action="viewisp"
text="setCurrentRowWithKey"
disabled="#{!bindings.setCurrentRowWithKey.enabled}">
<af:setActionListener from="#{row.rowKeyStr}"
to="#{processScope.rowKeyStr}"/>
</af:commandLink>
Page 1 JSPX Page Definition File Snippet:
<action id="setCurrentRowWithKey" IterBinding="SearchViewIterator"
InstanceName="SearchDataControl.SearchView"
DataControl="SearchDataControl" RequiresUpdateModel="false"
Action="96">
<NamedData NDName="rowKey" NDValue="#{row.rowKeyStr}"
NDType="java.lang.String"/>
</action>
JSPX Page 2 (destination - single form) - Page Definition Snippet:
<executables>
<iterator id="SearchViewIterator" RangeSize="10" Binds="SearchView"
DataControl="SearchDataControl"/>
<invokeAction id="setCurrentRowWithKeyStr" Binds="setCurrentRowWithKey"
RefreshCondition="#{adfFacesContext.postback==false}"/>
</executables>
<action id="setCurrentRowWithKey" IterBinding="SearchViewIterator"
InstanceName="SearchDataControl.SearchView"
DataControl="SearchDataControl" RequiresUpdateModel="false"
Action="96">
<NamedData NDName="rowKey" NDValue="#{processScope.rowKeyStr}"
NDType="java.lang.String"/>
</action>
Finally - I did see some other posts related to the JBO-25020 error. The recommended Solution was to add the following code to the underlying ViewObjectImpl class:
protected void create()
{    setManageRowsByKey(true);
super.create(); }
This had no affect.
thanks for any help.....
ps what exactly is stored in the row.rowKeyStr? is it based on data columns in the row?

Answer 1

Finally got this to work - thought I would post the solution that worked for me here in case anyone else runs into this:
Note: Page#1 = Search Form - ADF parameter form and ADF read-only table (uses CommandLink to pass record to page#2)
Page#2 = ADF read-only form - uses same VO and same iterator as page 1
1. As Frank in his reply above, I don't need to use an ActionListener, but only use the commandlink for navigation. I did need also to set the current row when the user clicks the command link as described in the JDev help (Adding Tables | Setting the Current Object Using a Command Component) - this was a step I was missing before.
2. NOW, here is where it gets Interesting - to avoid the issues of:
a. page#2 not displaying the correct record selected, or, inconsistently displaying the correct record; and/or,
b. receiving a "JBO-25020: View row of key oracle.jbo.Key[num] not found in xxIterator"
I had to EITHER:
A. Set the SyncMode for the DataControl in databindings.cpx = Batch (as described in      http://www.oracle.com/technology/products/jdev/tips/muench/batchmode/index.html)
OR,
B. Keep the SyncMode for the DataControl as Immediate, BUT override the following method in ViewObjImpl as described in some previous forum threads related to JBO-25020 error:
protected void create()
{     setManageRowsByKey(true);
super.create(); }
This is what I found (after much trial & error) worked for me - I'm curious to see if others have come to the same conclusions.
thanks
Tom