Technical Articles
Working with select-options and ranges tables in modern ABAP
- 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, 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. |
Ranges? Select-options?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.
Have you got any helpful tips or tricks to share?
Let us know in the comments! 👇
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! 🙂
Thanks Andreas, glad the post helped 👍
Hi Laurens. Thanks for your blog! Here's a blog with my thoughts to deal with selection criteria (PARAMETERS and SELECT-OPTIONS) as class.
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.
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:
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.
That's a good point, Suhas Saha.
I've never considered the possible side effects of the inline declaration of ranges, like the negative impact on the quick fixes functionality.
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.
Good tip, thanks!
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
Bhaskar Nagula
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