The work area wa is not aligned correctly

[Former Member]

Dear Colleagues,  Please let me know why this "The work area wa is not aligned correctly"  occurs when we have the below code:

TABLES: TYSFLIGHT.  TYPES: BEGIN OF TTSFLIGHT, 

CARRID TYPE SFLIGHT-CARRID,

CONNID TYPE SFLIGHT-CONNID, 

END OF TTSFLIGHT.

DATA:TT_SFLIGHT TYPE TABLE OF TTSFLIGHT,     

WA_SFLIGHT TYPE TTSFLIGHT.

WA_SFLIGHT-CARRID = 'KF'.

WA_SFLIGHT-CONNID = '001'.

APPEND WA_SFLIGHT TO TT_SFLIGHT.

CLEAR WA_SFLIGHT.

INSERT TYSFLIGHT FROM TABLE TT_SFLIGHT.

IF SY-SUBRC = 0.   WRITE: 'data inserted'.  ENDIF.

The question here is that this piece of code was working fine. Here we create a type and declared work area and internal table of that type. Why is not we have to include the entire table structure of tysflight for the wa and internal table like below:

TABLES : TYSFLIGHT.

DATA :  ITAB LIKE STANDARD TABLE OF TYSFLIGHT.

DATA : WA_ITAB LIKE LINE OF ITAB.

WA_ITAB-CARRID = 'KF'.

WA_ITAB-CONNID = '001'.

APPEND WA_ITAB TO ITAB.

CLEAR WA_ITAB.

INSERT TYSFLIGHT FROM TABLE ITAB.  IF SY-SUBRC = 0. 

WRITE: 'data inserted'.  ENDIF.

Thanks, Ipsita

[Former Member]

Hi,

you can create an internal table and work area with a database table, it is better to use the complete table only if you are using all the fields or most of the fields.

Insted it will be a memory wastage. As you are using TYSFLIGHT. If i am right u are not using all the fields, so it is not preferable to use complete table to declare a structure.

[Former Member]

hi mohanty,

As goutam mentioned the performance-wise first code is better than the second one.

because memory wastage as well as time consumption is high in secondone.The reason is u are selecting all the fields in database table in structure.so, it is advisable to go with the first method that u have mentioned.

thanks,

MARIMUTHU.K

[Former Member]

Hi,

Did check the table TYSFLIGHT in data base? or did create the TYSFLIGHT table?

Regards,

Venkat.

[Former Member]

Go through the below prerequisites to use the workarea or internal table in open SQL statements

• The data type of the work area or row type of the internal table must not be deep or contain deep components. This excludes strings and special work areas for streaming and locators.
• The work area or row type of the internal table must be at least as long as the database structure and the alignment must match. For the DELETE statement, this prerequisite must only be met in the length of the primary key.
• If the work area or rows of the internal table are stuctured, the Unicode fragment view of the database structure must match that of the work area or the internal table in Unicode programs.
• If the work area or rows of the internal table are elementary, they must be character-type and flat in Unicode programs. The columns of the database structure must also be character-type and flat.
• If the work area contains strings as components or is itself a string, or if columns of type SSTRING, STRING, or RAWSTRING appear in the database structure, the work area must be compatible with the database structure.
• For the modifying operations INSERT, UPDATE, and MODIFY, the passed values must match the value range of the columns of the database tables. Otherwise, overflows and corresponding exceptions occur. This applies in particular for:
• Columns with numerical data types.
• Columns of the types SSTRING, STRING, or RAWSTRING. The strings of the work area must not be longer than the maximum length of the columns in the database structure. This length can be determined using the built-in function dbmaxlen.

Note

The work area or row structure of the internal table should always be built like the database structure. If you work in the Open SQL statement with a single database table or one view, a data object built the same way can be declared with reference to the relevant structure in the ABAP Dictionary. If you work with more than one database table (in the SELECT statement), a data object built the same way can be built as nested structure, which contains, as substructures, the structures of the single database tables or views in the sequence in which they are listed in the statement. No structure should be used in which all components lie on one level, as possible alignment gaps between the single database tables or views are not taken into account.

[amy_king]

Hi Ipsita,

Have you confirmed that database table tysflight exists in your system? What is its structure?

There are some prerequisites for the SQL insert statement. The ones I think that are causing a problem for you are:

1. The structure of the internal table must be at least as long as the database table structure.
2. The alignment of the internal table structure must match the alignment of the database table. Alignment has to do with how certain data types are stored in memory, so this essentially is saying the sequence of fields and their data types must match between the database table and the internal table from which you're inserting.

In practice, the easiest way to meet these prerequisites is to make sure that the database table and the table you are inserting from have the same structure.

Cheers,

Amy

[Former Member]

Hi All,

Thanks for the quick reply.

I understand that memory wise its advisable to use as many fields that we require rather than selecting all fields from the table.

In the above case:

The structure of the internal table is not as long as the database table structure.

Hence the alignment issue.

And the database exists in the system with fields like carrid ,connid,etc but the alignment issue occurs if the wa and internal table do not have a structure as the table containing all fields.

I just wanted to now how this code was working earlier .

I am facing this issue recently.

Thanks,

Ipsita