Mapping Problem with 2 ALV Tables after sorting

[Former Member]

Hi,

I have a context node INCIDENTS with a sub-node SUB_INCIDENTS.

The sub-node is filled via a Supply Function.

Both nodes are displayed in separate ALV Grids on the same view, which works pretty well.

The only problem I face is when I try to sort one of the ALVs, then I get an error "The node specified in mapping ( SUB_INCIDENTS) could not be found ".

I have no clue how to solve that, already tried to fill the sub-node with the ALV standard function "ON_STD_FUNCTION_AFTE", no effect.

Does anybody can imagine what might be the reason?

Best regards, Steffen

Edited by: Steffen Weber on Aug 27, 2008 2:55 PM

[steffen_weber]

Thanks, I see, the parent node looses its lead selection.

Is there any chance to set it manually via coding? I'm sure there mus be a way to solve.

If not, the only solution I see is to take the sub-node out of the parent-node and create a separate node on the same level like the parent-node

At the moment it is:

CONTEXT -->parent-node

.......................|

.......................--> sub-node

Solution might be:

CONTEXT -->parent-node

...............--> sub-node

But then I can't use a Supply Function any longer.

Rgds

Edited by: Steffen Weber on Aug 27, 2008 4:17 PM

[thomas_jung]

In general, having two ALVs for parent and then a sub node is not supported. Here is a section from the online help that describes what happens when a sort occurs on the parent node in ALV:

Important Exception: Sorting

Here ALV has to use the entire dataset so that the data records can be arranged in the new order. For this purpose, the ALV component temporarily takes control of the internal data table and invalidates the corresponding context node of your application during this time. This ensures that the application cannot access the context node while the ALV component is editing the internal data table.

Once the internal data table has been resorted, ALV rebuilds the context node, releases it again for the application, and displays the data accordingly.

This ensures that the internal data table is never copied. This is important because large volumes of data would considerably impact performance and memory space.

When you are planning your application, note the following side-effects of this mechanism:

● When the context node is invalidated, information about current selections, and in particular the lead selection, is lost.

● If your application has created subnodes for the context node, (master-detail scenario), these subnodes are lost as soon as the ALV component invalidates the context node. If the application then tries to access the subnodes, a runtime error occurs.

Because of the invalidation that is described here, the subnode leadselection is lost and is invalidated as well. This leads to the error you are encountering.