Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
WHen you dump for memory, you can look down through the dump to see which tables were unusually big. Sometines, these might be intermediate tables. In that case, you could consume them and then free the memory. In other cases, a table will be the problem which can never be freed. In those cases, there are tweo possibilities that come easily to mind.
select less data.
Suppose you had selected 5 years of data from BSEG. Cut back and select 1 year of data from BSEG.
there are basis settings that can to a small extent increase the size of memory that you have available. You basis team is most likely two resist this option however, as it can only be done for every process in SAP and not just yours.
Get done a SQL trace or debug and analyze how much data the the report fetching. If bulk data retrieval being done, narrow your selection criteria. If its lower, contact you basis team to check the swap and buffer memories.
Well the best way would be to increase the allocated memory for program run if you have to use the ALV and all the data along with it. some design questions that you might have to deal with are:
1.What kind of data are you selecting?
2. Do you need such huge data to be displayed?
3. Also assess if you need ALV i.e. is any ALV functionality going to be used after display?
4. Would a plain list o/p not suffice?
5. Would a design like multiple lists(interactive lists) possible help in reducing the memory overhead?
6. How about limiting the ALV o/p to say a max number of entries like 10000 that can be handled foreground execution for more suggest background processing.
Bluesky
