This blog gives a few tips to keep in mind when migrating your ABAP code to an SAP HANA database.
A basic rule is that ABAP applications are fully compatible with SAP HANA. However, there are a few fine points to note, which we’ll discuss here:
- Database-dependent ABAP code: If you use database-dependent ABAP code in existing developments, you must test it as with any data migration and adjust it for the SAP HANA database if necessary.
- Converting pool and cluster tables: When converting pool and cluster tables to transparent tables, problems may occur if you’ve relied on an implicit sort behavior in your developments or if you directly accessed the internal physical clusters or pools.
- Sort behavior: If no ORDER BY was specified in the SQL statement, the sequence in which the records are read is unpredictable.
If your existing applications have database-dependent code—for example, Native SQL via the EXEC SQL statement, the ABAP Database Connectivity (ADBC) interface, or database hints—these positions in the code must be checked. While database hints are no longer executed on the new platform when you migrate to another database, an exact check is always required for database-dependent SQL because errors may occur here unless you intervene.
Hints to the database (or also the database interface [DBI]) are given a database indicator in ABAP. This generally looks as follows: SELECT … %_HINTS <DB> ‘db_specific_hint’.
The hint is sent only to the database specified instead of the <DB> placeholder. This means that when the additional statement to the optimizer of the old database platform is converted to the new platform, it’s no longer sent to the optimizer of the new database. This concerns not only hints for the database but also specific instructions to the DBI. For a conversion, you must thus check whether the desired behavior on the old database platform should also be defined again by a hint on the new database platform. This is generally unnecessary for SAP HANA due to the modified architecture. Usually, no adjustment is necessary for the hints to the DBI, either. Here, we recommend that you use the default values for SAP HANA for the DBI.
You must always check database-dependent code for a conversion, even if standard SQL is involved. For database-specific SQL, you must first clarify what the code is to achieve. An SQL statement must then be written to deliver the same result on SAP HANA. If possible, you should use Open SQL for this.
Access to former pool or cluster tables is a point that should be emphasized separately. For pool and cluster tables, the DBI always performs an implicit sorting. This is lost after the conversion to a transparent table because no automatic ORDER BY is added here to the statement. Therefore, access to pool and cluster tables must be analyzed with regard to their sorting during a migration. In this case, the Code Inspector provides a separate check—Find Select for Pool/Cluster Tab without ORDER BY—so you can quickly and easily find such critical points in your own developments.
However, changes can also occur in the implicit sort behavior for existing transparent tables. Classic row-oriented databases are usually accessed via a primary or secondary index. Here, the data are often read in the desired sequence because they are read from the database in the sequence stored there when you use an index. However, this isn’t guaranteed, and this behavior isn’t a documented feature of Open SQL. The selected access path and the associated sorting can thus change at any time. You must use the ORDER BY addition instead if the data is to be selected in a specific sorting. This rule applies in particular to SAP HANA because the data are column-oriented, there is no secondary index, and the data can be read in parallel. Thus, such places involve a programming error that you should correct regardless of a migration to SAP HANA. The Code Inspector and the runtime check monitor (Transaction SRTCM) provide separate checks.
Problems may occur if a certain sorting is assumed in program sequences. This is the case, for example, when working with searches in internal tables with the BINARY SEARCH addition because a relevant sorting is essential there. However, there may also be surprises with the output of data if it’s suddenly not appearing in the desired sort order.
One last note: If you require a specific sorting of data when you access a database, use the ORDER BY addition explicitly.