Form refresh issue when adding view to form ds with inner or outer join

Situation explanation

Form refresh issue when adding view to form ds with inner or outer join -> form loses selected record when one of it's root DS childs are linked via inner/outer join.

Created simplified cust table simple list form which have 3 DS

CustTable (root)
CustGroup (a table outer joined to CustTable and addlink in init method)
CustGroupFinTagSourceView (a view outer joined to CustTable and addlink in init method)

Table works without any issues, but view loses selected record when clicking form refresh

Situation from form VS perspective

GIF Demo

Short demo
1. Refresh works as expected - does not lose selected record position when joined view DS is disabled, but table DS is not
2. Joined view ds enabled breaks this
3. task workaround enabled fixes, but maybe there is more elegant way achieving this?

Task method workaround

    public int task(int _p1)
    {
        #Task
        int             ret;
        CustAccount     custAccountBeforeRefresh;
        boolean         gridLosesRecordOnRefreshWorkaroundNeeded;
    
        // workaroundForRefreshEnabled =>
        gridLosesRecordOnRefreshWorkaroundNeeded = _p1 == #taskRefresh && workaroundForRefreshEnabled;
    
        if (gridLosesRecordOnRefreshWorkaroundNeeded)
        {
            custAccountBeforeRefresh = CustTable.AccountNum;
        }
        // workaroundForRefreshEnabled <=
    
        ret = super(_p1);
    
        // workaroundForRefreshEnabled =>
        if (gridLosesRecordOnRefreshWorkaroundNeeded)
        {
            CustTable_DS.positionToRecord(CustTable::find(custAccountBeforeRefresh));
        }
        // workaroundForRefreshEnabled <=
    
        return ret;
    }

Question

Can I achieve similar without workaround in task method?

Whole CustTableSimple.xml source

Attached as attachment.

CustTableSimple.xml

Categories:

Dynamics 365 Finance

Hi Lauras U,

1) Issue
- Form loses selected record after refresh when a View data source is added with inner or outer join
- The problem occurs only when the joined data source is a View and not a Table
- Refresh works correctly when only table-based joins are used
- Enabling the joined View data source causes the grid to reset position after refresh
- Manual workaround using the task method is required to retain the selected record

2) Reason
- The issue is caused by how the form query is re-executed when a joined View data source is included
- A View does not guarantee a stable 1:1 relationship or consistent ordering of records during query execution
- This leads to a re-evaluation of the dataset where the cursor position cannot be preserved automatically
- In the provided implementation the View is linked dynamically using addLink in the init method which influences query rebuild behavior on refresh - This can happen because views may introduce duplicate or missing records compared to table joins causing the form to lose its internal record reference
- The framework therefore resets the cursor position after refresh as it cannot reliably map the previous record

3) Resolution
- Prefer using table joins instead of views where possible to ensure stable dataset behavior
- Ensure that the joined data source maintains a strict 1:1 relation with the root data source to avoid cursor instability
- Set appropriate join properties such as LinkType and ensure relations are correctly defined at metadata level rather than runtime
- Avoid dynamic addLink usage in init if the relation can be defined directly in the data source properties
- Use OrderBy or sorting on the primary key to stabilize dataset sequence during refresh
- Consider using a display method instead of a joined view if only additional data display is required
- If a View is required ensure it returns distinct records aligned with the root data source key
- The task method workaround using positionToRecord is a valid and commonly accepted solution when framework limitations cannot be avoided
- Alternatively override executeQuery and restore cursor position after query execution for a cleaner approach than task interception
- Validate the behavior with different join types and dataset sizes to confirm stability before final implementation

For a more detailed answer, please provide more information.

Rg,

Alexander

*Due to the complex and different possibilities of deploying Dynamics 365 I highly recommend not to setup the application without some expert/partner or support. (For more information contact me under anassl@inno-solutions.info or visit www.inno-solutions.de)

*The Information comes directly from the manufacturer or provider and are validated (not guaranteed) up to date of creation of the posting.

References: