ALIAS fieldname

In a project I had the problem that we had to use dynamic structures. Of course not all of the structure was dynamically – there was a set of fields which are constant -, but the whole structure has been created dynmically.

We then had to aggregate this dynamic internal table on some constant fields. We used MOVE-CORRESPONDING <dynamic_structure> TO constant_structure to overtake all of the fields we knew to be in the dynamic structure.

I will show you here how you can set up an alias name for a fieldname.

I will not set up the example using dynamic structures and demonstrating the MOVE-CORRESPONDING, because this distracts us from the main solution I would like to show.

Database Structure

This is the origin structure:

The field SALE_FLAG results from incorrect spelling, lazy implementation of specifications or whatever and should be named SALES_FLAG.

As this table is in production you would need to do a lots of effort to rename this field to SALES_FLAG. To avoid loss of data, you must add a new field with the correct name (SALES_FLAG) and write a migration report to move the data from SALE_FLAG to SALES_FLAG. After that you will have to adapt all reports to use SALES_FLAG instead of SALE_FLAG.

The following solution is not that neat but helps getting along with a wrong fieldname.

.Include

You simply can replace the field SALE_FLAG by a new include that you can name whatever you want to. The include must contain the exact field definition of the origin table. If you do so you have exactly the same database structure than before.

so why should you do that? Because of named includes. You can name an include (group name) and give it a name where all the fields in this include can be addressed by.

You simply have to name that include SALES_FLAG and now you can use the field by its origin name and also by the alias name.

Using The Alias

The following example shows how you can use the alias fieldname in a program:

SELECT * FROM ztt1 INTO TABLE @data(lt_tt1) WHERE sale_flag = ‘X’.

LOOP AT lt_tt1 INTO data(ls_tt1).

   ls_tt1–sales_flag = ‘Y’.

   WRITE: / ls_tt1–matnr, ls_tt1–sale_flag.

ENDLOOP.

There is one restriction where this method does not work: You can not select data using the alias name:

SELECT * FROM ztt1 INTO TABLE @data(lt_tt1) WHERE sales_flag = ‘X’.

The compiler sends this message

In database operations, the flat view of the type structure is always

relevant. This means that alias components cannot be used. –

Advantages

The two advantages of this solution are:

1. You have access to a field with two names. As discussed before this might be very important especially when using a dynamic structure and MOVE-CORRESPONDIG.
2. The database structure does not change. You can change the database table as described above and all data will remain because the origin fieldname dows not change.

<offtopic>

Why is the command named MOVE? The origin field value is only copied to the target field, not moved. So shouldn’t the command be called COPY and COPY-CORRESPONDING?? 😉 (According to the disussion of readable or not by Timo John Horst Keller, Suhas Saha, Paul Hardy and others)