Working with select-options and ranges tables in modern ABAP

[LaurensDeprost]

• About ranges and select-options


• Convert internal tables to ranges


• Fill ranges directly from SELECT statements

About ranges and select-options

Ranges are internal tables with the same structure as a selection table. They are very useful for flexible reading of database data in ABAP. Ranges tables always consist of four columns:

Field	Description	Examples
SIGN	whether records should be in- or excluded	‘I’ = Include ‘E’ = Exclude
OPTION	the selection operator	‘EQ’ = Equal ‘BT’ = Between ‘GT’ = Greater than …
LOW	the lower limit of the interval	…
HIGH	the higher limit of the interval	…

Ranges? Select-options?

Ranges, or ranges tables, are internal tables containing the four columns listed above. They are declared with syntax TYPE RANGE OF.

Select-options, on the other hand, refer to selection criteria on selection screens, which are linked with automatically generated selection tables. These are global internal tables with header line, that share the same layout as ranges tables.

Convert internal tables to ranges

Since ABAP 7.40 the FOR operator allows simple conversion from internal table to ranges table, without the need of directly looping over the table.

DATA(material_range) = 

  VALUE rsdsselopt_t( 

    FOR material IN materials

      ( sign = if_fsbp_const_range=>sign_include 

        option = if_fsbp_const_range=>option_equal 

        low = material-matnr ) ).

To do the opposite and extract data from a ranges table, use CORRESPONDING together with MAPPING.

materials = CORRESPONDING #( material_range MAPPING low = matnr ).

 

 

Fill ranges directly from SELECT statements

Gone are the days when it was necessary to first select data and then loop over it to fill a range. With the current syntax, ranges can be filled directly in the SELECT statement.

SELECT 'I' AS sign, 

       'EQ' AS option, 

       matnr AS low, matnr AS high 

INTO TABLE @DATA(material_range) 

FROM mara.

 

Ranges allow for flexible openSQL selections

 

What is your experience using ranges tables and select-options in ABAP?
Have you got any helpful tips or tricks to share?
Let us know in the comments! 👇

[ahstelacon]

Nice summary!

I was not aware that you need to define a HIGH for the SELECT into an inline table, so that it has all attributes of a selection table.

If you only add the LOW the SELECT is working but once using the range the system gives the error ""LT_TEST_RANGE" does not have the structure of a selection table."

This blog helped me solve that! 🙂

[LaurensDeprost]

Thanks Andreas, glad the post helped 👍

[Michael_Keller]

Hi Laurens. Thanks for your blog! Here's a blog with my thoughts to deal with selection criteria (PARAMETERS and SELECT-OPTIONS) as class.

[LaurensDeprost]

Thanks Michael.

Cool blog, with an approach that seems very useful for older reports with a lot of selection criteria.

That said, the lack of the need to explicitly map to class attributes is intriguing even for simpler use cases. I'm going to experiment a bit when I make another report 🙂

[SuhaSaha]

Hi Laurens,

Personally i don't declare ranges inline in select statements. I rather define them explicitly at first and then fill them using the select:

data RANGE_OF_MATERIALS type range of MATNR.



select 'I' as SIGN, 'EQ' as OPTION, MATNR as LOW

  from MARA

  up to 10 rows

  into corresponding fields of table @RANGE_OF_MATERIALS.

I have had bad experiences when defining them inline.  For e.g., when using the quick-fixes in ADT, it doesn't (naturally) realize that the inline declared variable is a range and the results are therefore not optimal.

[LaurensDeprost]

That's a good point, suhassaha.

I've never considered the possible side effects of the inline declaration of ranges, like the negative impact on the quick fixes functionality.

[juan_suros]

There are a number of table types in the data dictionary that make it easy to pass ranges as parameters of Performs, Function Modules, and class methods.

Look for table types with names like    SHP_<>_RANGE_T     where "<>" is a data element.

You can use these existing tables as a guide for your own, as needed.

[Michael_Keller]

Absolutley! If you have a lot of selection criteria or there's a good chance that you will have them in the future, this approach is great. Something like a container for your selection criteria and you can treat them the object oriented way.

As you mentioned: The lack of mapping is a real problem. Sure, you have to keep compatibility but it hurts that everyone can bypass the object oriented character of programming.

[LaurensDeprost]

Good tip, thanks!

[bhaskar_nagula]

Hi Laurens,

The biggest disadvantage of using a range table is we can't use it in the select query if range table has more than 50000 records. However, if we use it then the following runtime error will occur in the production system.

Category: Unclassified Error
Runtime Errors: DBSQL_ARGUMENT_ERROR
Except:. CX_SY_OPEN_SQL_DB

[BaerbelWinkler]

bnagula

Hi Bhaskar,

IIRC then this is not a hard restriction based on the number of entries in the range table but varies dependent on database system used and the fieldlength the range-table is based on. The reason is, that a SQL-statement which the database can process has some size limit. Several years ago that threshold for us was ~2,000 entries in a range table and more than 5 times as much after switching to another database.

Cheers

Bärbel

[sh4il3sh]

I find this blog so unnecessary.

[sh4il3sh]

wow thanks for this Barbel. 🙂