When you are dealing with large selections, it could be required to "process only half" of the selection first, and the rest later (or in an alternate job - simultaneously). But how do you know what "Half" a table is ? A simple report can help you out: load balancing table content by reporting the key values for each block.
This small helper report can list the key values of any table (which has a single key, ignoring the MANDT field), to reveal which values you can use when setting up a variant for your selection. As example there is a MARA table with just over 780.000 entries, and we want to allow no more that 100.000 entries to be processed in a single report (interface ?) run.
Simply implement the report and start it. Fill in the table you want to check and the block size you want to use and the - in this case - material numbers are listed. So in the example above, selecting MATNR between 29476 and 53387DEC (which are material numbers (!)) would yield 100.000 materials.
This report works on tables with a single key field only (MANDT excepted). So what if you need to do a split on e.g. MARD ? The closest you could get is to use the MARA split on your MARD selection. Controls are all yours.
Note that the setup of this report is not embedded in an object oriented class, here's why: more likely than not, you may want to implement this setup in an LSMW setup, in which case the data definitions and logic are best made available in the simplest form.
Support for multiple key fields
Table RBKP with the incoming invoice header is a nice example where the setup for the loadbalancer for a single key field does not work. Therefore there is an additional parameter field available on the selection screen, in which a bit of SQL statement can be supplied. In the RBKP example, this could be used by filling in GJAHR = '2017', which will lead to a series of number-pairs for the 2017 documents.
All you need to do is ensure the same selection is also applied to the report selection you want to prepare.
Get your copy
.