ABAP - By Theme …(1)
Introduction to ABAP
ABAP Portability
The ABAP Programming Language
ABAP syntax
Syntax Conventions
Comments
ABAP Types and Objects
Data Types - Overview
ABAP Type Names
Built-in Elementary Data types and Complex Data Types
Numeric Types
User-Defined Data Types
Working with Complex Types
Strings
Typing Formal Parameters and Field Symbols
Data Objects - Overview
Visibility of Data Objects
Changing Data Objects
Named and Unnamed Data Objects
Structure of Data Objects
Static and Dynamic Data Objects
Binding Data Objects to Formal Parameters and Field Symbols
Validity Area For Data Objects in Events
Alignment of Data Objects
Byte Sequence
Literals
Use of Data Objects
Changeable Data Objects
Non-Changeable Data Objects
Character-Type Data Objects
Numeric Data Objects
Byte-Type Data Objects
Memory Required
References
Typed Data References
TYPES ... TYPE REF TO DATA
DATA ... TYPE REF TO DATA
Basic Statements
Types
TYPES
TYPES - Defining Simple Types
TYPES - Defining a Structured Type
TYPES - Defining an Internal Table Type
INCLUDE TYPE
TYPE-POOLS
Data Objects
DATA
Simple Field Definition
Defining a Structured Data Object
Defining an Internal Table
Defining a Common Data Area
CREATE DATA
Type Declaration for CREATE DATA
Reference Object for for CREATE DATA
Line Type for CREATE DATA
Tylbe Key for CREATE DATA
Creating a Reference to a Data Object
INCLUDE STRUCTURE
CONSTANTS
STATICS
LOCAL
FIELDS
TABLES
NODES
Finding Out the Attributes of Data Objects
DESCRIBE FIELD
DESCRIBE DISTANCE
Process data
Assigning Values
MOVE
MOVE-CORRESPONDING
WRITE ... TO
PACK
UNPACK
CONVERT DATE / INVERTED-DATE
CLEAR
FREE
COMPUTE: Arithmetic Operations
ADD
ADD-CORRESPONDING
SUBTRACT
SUBTRACT-CORRESPONDING
DIVIDE
DIVIDE-CORRESPONDING
MULTIPLY
MULTIPLY-CORRESPONDING
Exceptions for COMPUTE
Processing Byte Strings and Character Strings
CONCATENATE
SPLIT
SHIFT
CONDENSE
TRANSLATE
TRANSLATE: Additional Information
CONVERT TEXT
OVERLAY
REPLACE
Replacement by Pattern
Replacement by Position
FIND
SEARCH
Processing Individual Bits in Hexadecimal Fields
SET BIT
GET BIT
COMPUTE: Bit Operations
Type conversions
User-specific Input/Output Conversions
Field Symbols
FIELD-SYMBOLS
ASSIGN
ASSIGN - Basic Form
CASTING Addition
TYPE Addition
DECIMALS Addition
RANGE Addition
ASSIGN COMPONENT
ASSIGN INCREMENT
ASSIGN LOCAL COPY
ASSIGN - Dynamic
ASSIGN - TABLES Work Areas
ASSIGN - TABLES Work Areas in the Main Program Group
Runtime Errors for ASSIGN
UNASSIGN
Logical Expressions
Relational Operators for All Data Types
String Relational Operators
Byte Comparison Operation
Relational Operators for Bit Masks
Relational Operator: In Range (BETWEEN)
Relational Operator: Has Initial Value (IS INITIAL)
Relational Operators Field Symbol Assigned (IS ASSIGNED)
Comparison Operator: Valid Reference (IS BOUND)
Test for Existence of an Actual Parameter (IS REQUESTED)
Test for Transfer of an Actual Parameter (IS SUPPLIED)
Relational Operator: In Selection Criterion (IN)
Controlling the Program Flow
Conditional Switching
IF
ELSEIF
ELSE
ENDIF
CASE
WHEN
ENDCASE
ON CHANGE OF
ENDON
Loops
DO
ENDDO
WHILE
ENDWHILE
CHECK
Continue
EXIT ………(314)
Processing Large Datasets …(316)
Internal tables
Internal Tables - Overview
Table Types
Generic Table Types
Standard Key for Internal Tables
Key Definitions for Internal Tables
Specifying the Key of an Unstructured Internal Table
Attributes of Objects as the Key of an Internal Table
Change Individual Internal Table Rows
Performance Notes for Internal Tables
Internal Tables: Optimized Key Operations
Statements Explicitly Specifying the Work Area
Inserting and Deleting Table Entries in LOOPs
Cost of Index Maintenance when Inserting and Deleting
Rules for Locale-Specific Sorting
Internal Tables - Keywords
APPEND
INSERT itab
MODIFY itab
COLLECT
READ TABLE itab
READ TABLE ... Output
LOOP AT itab
ENDLOOP
AT - Control Level Processing
SUM - Control Totals
ENDAT
DELETE itab
REFRESH itab
DESCRIBE TABLE
EDITOR-CALL FOR itab
SORT itab
Extracts
FIELD-GROUPS
INSERT ... INTO
EXTRACT
LOOP
SORT
CNT - Control Break Counter
SUM - Control Totals ……(425)
Saving Data Externally …..(427)
Saving Data Objects as Clusters
SAP Memory and ABAP Memory
EXPORT TO MEMORY/DATABASE/SHARED BUFFER
Runtime Errors for EXPORT TO DATABASE
IMPORT FROM MEMORY/DATABASE/SHARED BUFFER
Exceptions for IMPORT FROM DATABASE
FREE MEMORY
DELETE -Delete a Data Cluster
Working With Files
OPEN DATASET
TRANSFER
READ DATASET
GET DATASET
SET DATASET
CLOSE DATASET
DELETE DATASET
Modularization Techniques
Organization of Modularization Units
Source code modules
Macros
DEFINE
END-OF-DEFINITION
Include Programs
INCLUDE
Procedures
Literals as Actual Parameters for Typed Formal Parameters
Subroutines
FORM
ENDFORM
PERFORM
Function modules
FUNCTION
ENDFUNCTION
CALL FUNCTION
CALL CUSTOMER-FUNCTION
RAISE
Methods
Special Topics
The SAP Authorization Concept
AUTHORITY-CHECK
Exception Handling
Class-Based Exceptions
TRY
CATCH
CLEANUP
ENDTRY
RAISE EXCEPTION
RAISING Addition for Procedures
Exception Texts
Exceptions in ABAP Statements
Exception Classes for ABAP Statements
Catchable Runtime Errors
CATCH SYSTEM-EXCEPTIONS
ENDCATCH
Alphabetical Overview of Catchable Runtime Errors
Assignment of Catchable Runtime Errors to Exception Groups
Runtime Errors
Debugging
ASSERT
BREAK-POINT
GET RUN TIME
SET RUN TIME CLOCK RESOLUTION
SET RUN TIME ANALYZER
Standardized Microseconds
Link to Performance Notes
SET EXTENDED CHECK
SYNTAX-TRACE
Time Stamp
Converting Time Stamps
GET TIME STAMP FIELD f
CONVERT ... TIME STAMP ...
GET TIME
Setting the Language Key
SET LANGUAGE
SET LOCALE
GET LOCALE
Dynamic Program Processing
Program
INSERT REPORT
READ REPORT
DELETE REPORT
EDITOR-CALL FOR REPORT
SYNTAX-CHECK FOR itab
GENERATE REPORT/SUBROUTINE POOL
LOAD REPORT
SCAN
Text elements
INSERT TEXTPOOL
READ TEXTPOOL
DELETE TEXTPOOL
Screen
EXPORT DYNPRO
IMPORT DYNPRO
DELETE DYNPRO
SYNTAX-CHECK FOR DYNPRO
GENERATE DYNPRO
Special Statements for Applications
INFOTYPES
PROVIDE
ENDPROVIDE …(741)
ABAP User Dialogs ……(742)
Screens
PROCESS
FIELD
MODULE
MODULE ... ON ...
SELECT
Values
CHAIN
ENDCHAIN
LOOP
ENDLOOP
CALL SUBSCREEN
ABAP Statements for Screens
Modifying Screens using the SCREEN Table
LOOP AT SCREEN
MODIFY SCREEN
SET HOLD DATA
SUPPRESS DIALOG
EXIT FROM STEP-LOOP
CONTROLS
CONTROLS ... TYPE TABSTRIP
CONTROLS ... TYPE TABLEVIEW
REFRESH CONTROL
SET PF-STATUS
GET PF-STATUS
SET TITLEBAR
SET CURSOR
GET CURSOR
Selection Screens
PARAMETERS
RANGES
SELECT-OPTIONS
SELECTION-SCREEN
SELECTION-SCREEN: Defining Selection Screens
SELECTION-SCREENS: Designing Selection Screens
SELECTION-SCREEN: Formatting on Selection Screens
SELECTION-SCREEN INCLUDE
SELECTION-SCREEN: Special Variants for Logical Databases
SELECTION-SCREEN: Special Variants for Logical Databases
CALL SELECTION SCREEN
Modification Groups on Selection Screens
Definition of Titles and Texts on Selection Screens
Dynamic Selections
Dynamic Selections on Selection Screens
Dynamic Calls
Lists
LEAVE TO LIST-PROCESSING
LEAVE LIST-PROCESSING
Creating and Processing Lists
Creating Simple Lists
WRITE
Predefined Output Formats
WRITE - Formatting Options
WRITE ... AS CHECKBOX
WRITE ... AS SYMBOL
WRITE ... AS ICON
WRITE ... AS LINE
ULINE
SKIP
NEW-LINE
NEW-PAGE
TOP-OF-PAGE
END-OF-PAGE
SET BLANK LINES
Using Values Greater Than 255 With LINE-SIZE in Lists.
System Fields for Lists
Notes on the Use of LINE-COUNT
Creating Complex Lists
FORMAT
DETAILS
SUMMARY
RESERVE
POSITION
BACK
SCROLL
SET LEFT SCROLL BOUNDARY
SET COUNTRY
Creating Interactive Lists
HIDE
WINDOW
READ LINE
MODIFY LINE
SET USER-COMMAND
DESCRIBE LIST
Printing Lists
General Information on Printing
NEW-PAGE PRINT ON
NEW-PAGE PRINT ON (Obsolete Additions)
NEW-PAGE PRINT OFF
SET MARGIN
PRINT-CONTROL
SUBMIT TO SAP-SPOOL
Messages
MESSAGE
ABAP Program Execution …..(1002)
Processing blocks
LOAD-OF-PROGRAM
INITIALIZATION
START-OF-SELECTION
GET
END-OF-SELECTION
MODULE
ENDMODULE
CHECK
REJECT
STOP
RETURN
Introductory Statements for Programs
PROGRAM
REPORT
CLASS-POOL
INTERFACE-POOL
TYPE-POOL
Screen Sequences
CALL SCREEN
SET SCREEN
LEAVE SCREEN
LEAVE TO SCREEN
Starting programs
Calling an Executable Program
SUBMIT
Passing Parameters in SUBMIT
Calling a Transaction
CALL TRANSACTION
LEAVE TO TRANSACTION
Dialog modules
CALL DIALOG
Passing Data Using SPA/GPA Parameters
SET PARAMETER
GET PARAMETER
Leaving a Called Program
LEAVE PROGRAM
LEAVE ..…(1058)
ABAP Database Accesses ….(1060)
Relational Databases
Open SQL
SELECT
SELECT Clause
INTO Clause
FROM Clause
WHERE clause
GROUP-BY Clause
HAVING Clause
ORDER-BY Clause
ENDSELECT
Subquery
INSERT
UPDATE
MODIFY
DELETE
OPEN CURSOR
FETCH
CLOSE CURSOR
Exceptions in OPEN SQL
Dynamic Source Text in Open SQL
Logical Condition in Database Access Statements
Dynamic Logical Condition in Open SQL
Field Label
Column Reference
Aggregate Functions
Strings in Database Tables
Secondary Database Connections
Structure of Database Tables
Performance Tips for Open SQL Programming
Indexes
Native SQL
EXEC SQL
ENDEXEC
EXIT FROM SQL
Logical databases
Naming Conventions for Logical Databases
PUT dbtab
Contexts
CONTEXTS
SUPPLY
DEMAND
Transaction Processing
Database Integrity
Logical Unit of Work (LUW)
Locking
Database Locking
SAP Locking
Locking Conflicts During Database Read Access
COMMIT WORK
ROLLBACK WORK
CALL FUNCTION ... IN UPDATE TASK
SET UPDATE TASK LOCAL …(1243)
ABAP Objects ……(1245)
ABAP Objects - Overview
Defining Classes and Interfaces
Classes
Class components
Visibility Sections in Classes
Attributes
Methods
Interface Parameters in Methods
C Destructor
Kernel Methods
Constructors
Visibility of Instance Constructors
Events
Types and Constants in Classes
Inheritance
Redefining Methods
Abstract and Final Methods in Classes
References to Subclasses and Polymorphism
Inheritance and Interfaces
Component Visibility
Namespace of Components
Inheritance and Static Attributes
Inheritance and Constructors
Inheritance and Instance Generation
Interfaces
Nested Interfaces
Friends
Objects
Object references
Accessing Class Components
Accessing Attributes by References in Internal Tables
Operators in ABAP Objects
Statements in ABAP Objects
Statements for Defining Classes and Interfaces
Statements for Implementing Methods
Statements in Class and Interface Pools
Replacement of Obsolete Statements in ABAP Objects
Incorrect Syntax
Type Definitions and Data Declarations
Assignments
Offset/Length Specifications
Character String Processing
Field Symbols
Logical Expressions and Control Structures
Internal tables
Procedures
Data Cluster
Program Calls
Database accesses
Lists
Reporting
ABAP Objects - Keywords
CLASS
PUBLIC SECTION
PROTECTED SECTION
PRIVATE SECTION
ENDCLASS
CLASS-DATA
CLASS-METHODS
CLASS-EVENTS
METHODS
EVENTS
INTERFACES
ALIASES
METHOD
ENDMETHOD
INTERFACE
ENDINTERFACE
CREATE OBJECT
CALL METHOD
RAISE EVENT
SET HANDLER
Special Variants of Other Keywords
TYPES ... REF TO cif
DATA ... REF TO cif
DATA ... READ-ONLY
MOVE METH( ... ) TO ...
MOVE ... ?TO ...
COMPUTE ... ?= ...
ABAP System Classes
Classes for Determining Type Attributes at Runtime
Classes for Character Set and Number Format Conversion
Class for Mathematical Operations
Class for Calculating with Time Stamps
Classes for Specifying Field Attributes
Classes for Data Clusters
Class To Get Transaction Status
ABAP - Object Services
Persistence Service
Transaction Service ….(1478)
ABAP Unicode …..(1480)
Names and Declarations
Access with Offset and Length
Assignments
Handling Structures like a Single Component
Comparisons
Casting Field Symbols
Type Checks and Type Compatibility
Structure Typing Compatibility
Byte String and Character String Processing
Determine Length and Distance
Key Entries for Table Accesses
Storage of Cluster Tables in Database Tables
File interface
Database operations
Structure Enhancements
Other Changes
Special Statements for Unicode Programs
String Processing for Byte Sequences
Determine Length and Distance
Assignments to Field Symbols
Offset/Length Accesses with Group Names
Data Object Generation
Dynamic Field Assignments
Storage of Cluster Tables
File interface ….(1523)
ABAP Data and Communication Interfaces ….(1525)
Batch input
Cross-Transaction Application Buffer
CPIC
COMMUNICATION
RFC - Remote Function Call
CALL FUNCTION ... DESTINATION (synchronous RFC)
CALL FUNCTION ... IN BACKGROUND TASK (transactional RFC)
CALL FUNCTION ... STARTING NEW TASK (asynchronous RFC)
RECEIVE RESULTS FROM FUNCTION (asynchronous RFC)
WAIT UNTIL logexp (asynchronous RFC)
Define Remote Destinations (RFC)
RFC Logon in Target System (Remote Logon)
Trusted/Trusting Systems (RFC)
RFC Authorization Concept
Typical RFC Problems with Solutions
OLE2 Automation
CREATE OBJECT
SET PROPERTY
GET PROPERTY
CALL METHOD
FREE OBJECT
CALL cfunc
CALL TRANSFORMATION ….(1607)
ABAP and JavaScript ….(1612)
Classes in JavaScript …..(1612)
ABAP - Overview Diagrams …..(1613)
Alphabetical Overview of ABAP
ABAP and Unicode
ABAP System Fields
Classification of Key Words by Type
Example Programs
Obsolete Keywords
Obsolete Variants of the READ Statement
ABAP - Tools …..(1647)
ABAP - Workbench Tools
ABAP - Runtime Tools
ABAP Changes by Release ….(1648)
Changes Before Release 3.0
Changes in Release 3.0
Declarative statements
RFC - Remote Function Call
Logical Databases and Selection Screens
String Processing
Internationalization
List Processing
Debugger
Arithmetic Expressions
Assigning Types to Formal Parameters
Displaying Icons on Screens
OLE2 Automation Controller
Open SQL
Messages
Miscellaneous
Changes in Release 4.0 and 4.5
Catchable Runtime Errors
Bit Operations and Bit Comparisons
Data Types in the ABAP Dictionary
Processing Large Datasets
Extended Field Symbol Concept:
Internal Tables - Key Tables
Internal Tables and Extracts
Runtime Analysis
Open SQL
RFC - Remote Function Call
Selection Screens
Logical Databases
Time Stamp
Additional Changes in Release 4.0
Additional Changes in Release 4.5
Introduction of ABAP Objects
Runtime Analysis
ABAP Objects - Inheritance and Nested Interfaces
ABAP Objects - Dynamic Method Call
ABAP Objects - Other Developments
ABAP Objects - Obsolete Statements
New Data Types STRING and XSTRING
Data Objects and Data References
Data and Object Type Description at Runtime
Named Includes
Casting Arbitrary Data Types
Dynamic Offset and Length Access
Internal Tables
Runtime Analysis
Debugger
Other Developments
Other Changes
Changes in Release 4.6C
ABAP Objects
Optimizations in the Runtime System
Runtime Analysis
Other Changes
Changes in Release 6.10
Unicode
ABAP Objects
Object Services
Internal Tables
Character Strings
File interface
Compiler
Runtime and Load Size
Type Concept
SQL and Updates
Exception Handling
Data References
Using JavaScript with ABAP
Debugger
Coverage Analyzer
List Processing
System Fields
Other Changes
Changes in Release 6.20
ABAP Objects
Structure Enhancements
Exceptions that Can Be Handled
Extras
Short Dumps
Tools
ABAP - By Theme
ABAP ProgrammingThis documentation describes the syntax and meaning of ABAP (Advanced Business Application Programming) key words.
For more information on the concepts underlying ABAP programming in the R/3 System, see the following topic in the application help:
BC ABAP Programming
For executable example programs, see: Library of Examples
Introduction to ABAP
ABAP IntroductionAn introduction to the R/3 Basis System and the ABAP programming language is available in the SAP Library:
ABAP Basics
ABAP Portability
Notes on the Portability of ABAP
The nature of SAP Basis software guarantees that ABAP programs can be
supported by many different systems. There are only a few cases where transfer of programs to other platforms could cause problems.
Native SQL
Database-specific statements enclosed by EXEC SQL and ENDEXEC are the most critical factor for portability. Whenever possible, you should use ABAP/4 Open SQL.
Files
A parameter of the OPEN, CLOSE, TRANSFER, READ DATASET and
DELETE DATASET statements is a file name which is passed to the underlying
operating system. However, the organization of file systems (flat, hierarchical, ...) and the form of valid file names depends to a great extent on the operating system.
The function module FILE_GET_NAME allows you to convert logical file names (platform-independent) to physical file names (platform-specific).
Numeric format
The format of numeric types I and F can be represented by various byte
sequences. With type F, even the code is different. Here, support is provided by the TRANSLATE ... NUMBER FORMAT command.
Numbers
While numbers of type P and I are treated in the same way on all platforms supported by SAP, there are differences with floating point numbers (type F). Although the value range (about 10**(-308) to 10**(+308)) and accuracy up to 15 decimal places is the same everywhere, rounding behavior can vary. These
differences should not have any serious consequences in practice, but it is not advisable to test two floating point numbers for equality, with the exception of zero; instead, check that the difference is only very small as shown below.
DATA: F TYPE F, G TYPE F, REL_DIFF TYPE F,
EPSILON TYPE F VALUE '1E-6'. REL_DIFF = ABS( ( F - G ) / G ). IF REL_DIFF < EPSILON. ... ENDIF.
Alignment
Certain fields are aligned at the half word or word limit in field strings. As a result, these field strings may contain leading bytes, even before the first field.
Furthermore, some ABAP/4 types are different, depending on the platform. For this reason, you should always address components of a field string by name and not with an offset value, i.e. T000-ORT01 rather than T000+28.
The set of available characters and their coding depends not only on the platform, but also on the country and language of installation. The TRANSLATE ... CODE
PAGE command allows you to convert texts from one coding to another.
Sorting
You can only make very limited assumptions about the effect of sorting on the character sequence. For instance:
• Lower case letters can come before upper case letters or vice-versa. • Numbers can come before letters or vice-versa.
• While the numbers 0 to 9 follow each other with no gaps, this is not necessary for letters. Letters with an accent are not sorted.
These problems affect the SORT, READ TABLE ... BINARY SEARCH and
SELECT ... ORDER BY statements, as well as the comparison operators <, <=, >, >=, BT and NB. Unfortunately, there is no general solution at present. There is
a special solution for the SORT statement. This is "locale" sorting, using the AS
TEXT addition.
The ABAP Programming Language
ABAP Programming LanguageThis section describes the ABAP programming language. For further information refer to The ABAP Programming Language in the SAP Library.
ABAP syntax
ABAP SyntaxThis section contains notes on ABAP syntax. For more information, see also: ABAP Syntax
Syntax Conventions
Syntax conventions in the ABAP keyword documentation
The ABAP keyword documentation uses the following syntax conventions: • Keywords and additions are written in uppercase.
Example:
APPEND, NON-UNIQUE, INTO, ...
• Placeholders and other non-keywords are written in lowercase. Example:
obj, linetype, tabkind, ...
• Alternatives are separated by vertical lines and are enclosed in brackets or braces.
• Optional arguments are enclosed in brackets. If there are several options, all symbols until the next vertical line or closing bracket are to be regarded as a single option.
Example:
[WITH HEADER LINE]
• Selection lists are enclosed in brackes. You must use one element from the list. The list must contain at least two options.
Example:
{UNIQUE|NON-UNIQUE}
Comments
Comments in ABAP/4 Programs
To make programs more readable and easier to maintain, they should always contain comments which describe the effect of certain statements at the relevant places.
• The whole line is considered to be a comment if there is an asterisk (*) in the first column.
These comments are highlighted in a different color in the editor.
• Any part of a line beginning with a quotation mark (") is also a comment. However, this applies only if the quotation mark is not itself within a character-type literal. Such literals always begin and end with quotation marks (').
Introducing blank lines at strategic points can also improve the readability of programs.
ABAP Types and Objects
ABAP Types and ObjectsIn ABAP we have to distinguish between types and objects. While types are simple descriptions that do not use storage, objects are instances of types using storage. A type specifies the technical properties of all objects of that type. The ABAP types make up the ABAP type hierarchy:
Hierarchy of ABAP Types
Types ---- Data types ---- Elementary ---- Fixed length--- C | | | |-- N | | | |-- D | | | |-- T | | | | | | | |-- X | | | | | | | |-- P | | | |-- I | | | |-- F | | |
| | |-- Var. length--- STRING | | |-- XSTRING | |-- Reference types | | | |-- Complex ---- Structured | |-- Table type |
|-- Object types --- Classes |-- Interfaces
We basically distinguish between data types and object types.
• Data types describe data objects. They are further subdivided into
elementary, reference, and complex types. There are built-in (predefined) data types, and they can be defined locally in the program or system-wide in the R/3 Repository.
• Object types describe objects in ABAP Objects. They are further
subdivided into classes and interfaces. Object types contain the above data types on the one hand, but also functions on the other hand. Object types are not built-in, but must be defined in the program or in the R/3
Repository. Classes describe an object completely. They define which data types and which functions an object contains. Interfaces describe a partial aspect of an object. The data types and functions of an interface can be implemented by several classes.
The hierarchy of the ABAP objects reflects the ABAP type hierarchy: Hierarchy of ABAP objects
Instances ---- Data objects ---- Elementary ---- Static ---- C | | | |-- N | | | |-- D | | | |-- T | | | | | | | |-- X | | | | | | | |-- P | | | |-- I | | | |-- F | | | | | |-- Dynamic ---- STRING | | |-- XSTRING | |-- Reference variables | | | |-- Complex ---- Structures | |-- Internal tables | |-- Objects
• Data objects are fields in the proper sense of the word. They contain the data local in the program used by the program at runtime.
• Objects are genuine software objects in ABAP Objects and support object-oriented programming because they contain not only data but also methods and events.
Data Types - Overview
Data TypesData types are mere type descriptions with no memory involved. A data type characterizes the technical properties of all data objects that have this type. Data types occur as attributes of data objects but can also be defined independently. The definition of independent data types builds on a set of predefined data types. It can be included in the declaration part of a program using the statements TYPES or defined generally in the ABAP Dictionary. Independent data types can be used to declare data objects and for type checks in generic operations.
Data types are a subtree of the ABAP type hierarchy: Hierarchy of ABAP data types
Data types ---- elementary ----fixed length---- C | | |-- N | | |-- D | | |-- T | | | | | |-- X | | | | | |-- P | | |-- I | | |-- F | | | |-- var.length ---- STRING | |-- XSTRING |-- reference types | |-- complex ---- structured
Data types are subdivided into elementary types, reference types, and complex types.
• Elementary types are atomic, that is they are not a combination of other types. They are subdivided into fixed-length and variable length types.
o ABAP includes eight built-in elementary data types with fixed length: a. four character-type types: character fields (C), numeric character fields (N),
date fields (D), time fields (T)
b. X for byte fields with hexadecimal display
c. three numeric types: integer (I), floating-point numbers (F), and packed numbers (P)
o ABAP includes two variable-length elementary types:
a. STRING for character strings b. XSTRING for byte sequences
• Reference types describe data objects that include references to other objects (data objects and objects from ABAP Objects). Reference types form a hierarchy that represents the hierarchy of the objects to which the references point.
• Complex types are combined of other types. They make it possible to manage and process semantically related data sets under one name. Complex-type data objects can be accessed as a whole or by component. ABAP does not have any built-in complex data types. A complex data type must either be defined in an ABAP program or in the ABAP dictionary. Complex data types are subdivided into structures and internal tables.
o A structure (record) is a sequence of any elementary, reference, or complex data types. Structures are used in ABAP programs to combine work areas that are logically related. Since the individual structure elements can have any data type, structures can be used in many different ways.
o Internal tables consist of a sequence of lines with the same data type. Tables are characterized by:
a. the line type, which can be any elementary data type, a reference type or complex data type
b. a key to identify the table lines. It can be built up from the elementary fields of the lines. Distinction is made between unique and non-unique keys.
c. the access type that defines how ABAP accesses the table. With respect to the access type, distinction is made between sorted and unsorted index tables and
hash tables.
Internal tables are always used when multiple data of a fixed structure are used within the program.
For further information refer to Data Types in the SAP Library.
ABAP Type Names
ABAP Type Names
Every explicit type, that is, all types defined in the ABAP Dictionary or or in the ABAP source code using TYPES command, has a relative type name and an absolute type name. Implicit types are created when, at the DATA command in the TYPE specification, a new type is derived from an existing one, for example, using REF TO or LINE OF. These implicit types do not have a relative type name but the system generates a technical absolute type name. Technical absolute type names are assigned as long as the program, in which the type is located, is not changed.
Example
TYPES:
my_ref_type TYPE REF TO c01. DATA:
ref1 TYPE my_ref_type, ref2 TYPE REF TO c01.
The variable REF1 was created with an explicit type, that is, the type of the variable REF1 has the type name MY_REF_TYPE. The variable REF2 was created with a type which was first implicitly constructed in the DATA statement. This means that the type of variable REF2 does not have a type name.
Relative Type Names
Relative type names are not unique. The point in the program, at which type is used, defines which type is meant. Each type name assigned in the Dictionary or in the TYPES statement is a relative type name.
Absolute Type Names
Absolute type names are unique within a system. It is not important in which area the type name is used. The name always points to the same type. This prevents
types from being hidden by other types. Absolute type names can only be specified dynamically. This means you can use them only for those statements supporting the dynamic variant of the TYPE addition.
Unlike relative type names, absolute type names contain additional information about the context in which the type was defined. For this purpose, absolute type names are subdivided into sections (tags), similarly to the path of file names. The individual tags are separated by a backslash (\). An absolute type name always begins with a backslash. The following tags are allowed:
• \TYPE=name • \CLASS=name • \INTERFACE=name • \PROGRAM=name • \CLASS-POOL=name • \FUNCTION-POOL=name • \TYPE-POOL=name • \METHOD=name • \FORM=name • \FUNCTION=name
Absolute type names always end with one of the following three tags: • \TYPE=name for data types
• \CLASS=name for classes
• \INTERFACE=name for interfaces
If an absolute type name consists of only one of these three tags, it is a global type (Dictionary), a global class, or a global interface.
Example
PROGRAM my_program. ...
TYPES my_type TYPE i. ...
CLASS my_class DEFINITION. PUBLIC SECTION.
METHODS my_method. ENDCLASS.
...
CLASS my_class IMPLEMENTATION. METHOD my_method.
TYPES my_type TYPE f. ...
ENDMETHOD. ENDCLASS.
Two types were defined in this program. Both types have the relative type name
MY_TYPE. The point in the program where the type is used defines which type is
referred
However, both types have a different absolute type name: • \PROGRAM=MY_PROGRAM\TYPE=MY_TYPE
for the type declared at the beginning of the program using TYPES
my_type TYPE i.
• \PROGRAM=MY_PROGRAM\CLASS=MY_CLASS\METHOD=MY _METHOD\TYPE=MY_TYPE
for the type declared within the method MY_METHOD using TYPES
my_type TYPE f.
Both types can be uniquely identified in all areas of the program by the absolute type name.
Built-in Elementary Data types and Complex Data
Types
Built-in elementary data types and complex data types
ABAP contains a range of built-in elementary data types: Character (text),
Numerical character (number string), Date, Time Integer, Floating point number, Packed number, and HeX code). Some of these data types are fully types (D, T, I,
F), others (C, N, P, X) are generic, in the sense that you must provide further type information (length, for type p also the number of decimal places) when you create the data object (DATA).
In addition to the elementary data types C and X, which always refer to a fixed-length memory area (to be specified when the data objects are created), there are two corresponding data types with dynamic memory management. Their length is automatically adjusted to the requirements of the data object to be stored. These types are character strings ( STRING and) byte sequences (XSTRING).
In addition to the elementary data types, ABAP provides two options to create
complex data types:
• By combining components of any type to form a structure (record). • By using a line of any type to form an internal table.
You can use structures and internal tables to create both complex data types and directly to create complex data objects.
Numeric Types
ABAP Numeric TypesABAP supports three numeric data types - I, P and F. Type N is a text type, not a numeric data type (although its values are strings of digits), because the strings are not used for calculation purposes. Typical examples of type N fields are account and article numbers (provided they contain only digits), as well as the sub-fields of date and time fields.
Calculations involving type I or F fields correspond more or less directly to
machine commands. In contrast, calculations involving packed numbers (type P) are programmed, and thus noticeably slower.
Type I values are integers in the range +/- 2 billion, or, exactly, from -2147483648
to 2147483647. Intermediate results in type I expressions are stored in type I auxiliary fields. Otherwise, type I arithmetic is similar to performing calculations with type P fields without decimal places; division (using the operator /) rounds numbers rather than truncating them. Overflow results in a runtime error.
Type I is typically used for counters, quantities, indexes and offsets such as time periods.
The value range of type P fields depends on their length and the number of
decimal places. P fields can be 1 to 16 bytes long, with two decimal digits packed into each byte, and one decimal digit and the sign packed into the last byte. There can be up to 14 decimal places. Auxiliary fields for intermediate results are always 16 bytes long and can thus hold up to 31 decimal digits. To ensure that the decimal point is correctly calculated, you should always set the program attribute "fixed point arithmetic". Otherwise, all numbers are specified as integers and all
not set, the decimal places defined for the number only appear when outputting with WRITE.
Fixed point arithmetic is decimal arithmetic and is similar to using a pocket calculator or calculating with paper and pencil.
Type P is typically used for sizes, lengths, weights and sums of money.
Rule: If you want to calculate "down to the last penny", you should use the type P.
Type F values range from +/- 2.2250738585072014E-308 to
1.7976931348623157E+308, as well as the number 0, with an accuracy of at least 15 decimal places.
You cannot enter floating point numbers directly in your programs. Instead, you must use text literals that can be interpreted as floating point numbers. You may use the following formats:
Decimal numbers with or without sign, with or without decimal point. The form <mantissa> E<exponent>, where the mantissa is a decimal. The exponent may be specified either with or without sign. You may also use spaces before or after the number. Examples of text literals with "floating point numbers":
'1', '-12.34567', '-765E-04', '1234E5', '+12E+34', '+12.3E-4', '1E160'.
Use floating point arithmetic if you need a very large value range or you are making decimal calculations, but be aware of the following features of floating point arithmetic.
Internally, the exponent and the mantissa of floating point numbers are stored separately, each in two parts. This can lead to unexpected results, despite the high degree of intrinsic accuracy. These occur mainly when performing conversions from and to type F.
For example, the number 1.5 can be represented exactly in this notation, since 1.5 = 1*2**0 + 1*2**(-1), but the number 0.15 can only be represented approximately by the number 0,14999999999999999. If you round 0.15 up to 1 valid digit, the result is 0.1 rather than 0.2 as you would expect. On the other hand, the number 1.5E-12 is represented by the number 1.5000000000000001E-12, which would be rounded to 2E-12.
Another example which actually occurred is the calculation of 7.27% of 73050 to an accuracy of 2 decimal places. The intermediate result
5.3107349999999997E+03, since the correct result, 5310.735, cannot be
represented exactly in two parts with 53 bits. (If the hardware cannot represent a real number exactly, it uses the next representable floating point number. After rounding, you therefore get 5310.73 rather than 5310.74 as you would expect. The ABAP runtime system calculates commercially and not "numerically" like the underlying machine arithmetic. According to the rounding algorithm of the latter, the end digit 5 must always be rounded to the nearest even number (not the next largest number), i.e. from 2.5 to 2, 3.5 to 4.
You should also note that multiplication using powers of 10 (positive or negative), is not an exact operation. For example, although 100.5 can be represented exactly
in two parts, after the operation F = F / 100 * 100
F has the value 100.49999999999999.
As well as rounding errors, the restricted number of decimal places for the mantissa can lead to the loss of trailing digits. For example, 1 -
1.0000000000000001 results in zero.
This means that you cannot rely on the last digits in floating point arithmetic. In particular, you should not usually test two floating point numbers for equality; instead, you should check whether the relative difference abs((a - b)/a) is less than a predefined limit, e.g. 10**(-7).
User-Defined Data Types
User-Defined Data TypesUser-defined data types allow you to define your own range of application-specific data types. You caon do this centrally, and thus make the types available
throughout the ABAP programming environment. Local Types in Programs
You can store user-defined types either locally in a program, or centrally in the ABAP Dictionary.
The TYPES statement allows you to create local types in a program. User-defined types can be either elementary or complex.
The syntax of the TYPES statement is similar to that of the DATA statement that you use to declare data objects.
You can use user-defined data types anywhere where you could use predefined data types, that is, to create data objects, or to specify the types of formal parameters and field symbols.
Global Types
Global types are stored in the ABAP Dictionary, either as elementary types (data elements), or as complex types, constructed from existing elementary data types. As well as "real" data types, the ABAP Dictionary still contains type groups, A type group is a segment of ABAP code that you maintain in the ABAP editor. Its first statement is TYPE-POOL. Type groups can contain definitions of both types and constants. The names of all of the types and constants in a type group must be prefixed by the name of the type group itself, followed by an underscore. To address types from a type group in a program, you must declare the gropu in the program using the TYPE-POOLS statement.
Working with Complex Types
Working with Complex TypesComplex types can be made up of either elementary types or from other complex types. For example:
• Structures can contain components of any type • Internal tables can be defined from any line type
The fact that structures can contain components of any type means, in particular, that:
• Structures can contain sub-structures (nested structures) • Tables can be components of structures (deep structures)
The fact that internal tables can be defined using any line type allows you to create:
Daß interne Tabellen über Zeilen beliebigen Typs definiert werden können, erlaubt insbesondere die Vereinbarung von
• Tables of unstructured line types (dynamic arrays of elementary types) • Tables of structures with tabular components (tables with a deep line type) • Tables of tables
Complex data types allow you to model complex data objects. You can aggregate fields, structures, and internal tables in one declaration. The inner structure of the data object can be encapsulated so that interfaces can be more streamlined. Internal tables that are part of a complex data object never have a header. This allows you to define basic operations on any data object in an uncontrived way. Only internal tables at the top level of an object can (but need not) have a header.n aber nicht) eine Kopfzeile haben.
If itab is an internal table with a header, you can address the table body using
itab[].
Basic universal operations
Complex data types and objects are integrated seamlessly in the ABAP language. SAP has defined a range of operations that can be performed on any data object.
The semantics for complex data objects are uncontrived because they are based on the equivalent operations on elementary objects.
At present, the following ABAP statements have been defined for use with any data object:
• MOVE :
MOVE for structures entails a assignment component-by-component.
MOVE for internal tables entails copying the content of the table (that is, "deep copy" as opposed to a "shallow copy").
• Comparisons using:
o Logical expressions (IF, CHECK, WHILE), o Sorting (SORT) and
o Control break processing (AT NEW / AT END OF, ON CHANGE OF): Two structures are considered equal if each component is of the same type. A structure is considered smaller than another if it contains the first smaller component in the predefined component order.
Two internal tables are considered equal if they have the same number of lines and are identical line-by-line in the predefined line order. A table is considered smaller than another if it has fewer lines, or if it has the same number of lines but contains the first smaller line in the predefined line order.
• Reset to initial (CLEAR):
For structures, CLEAR entails a component-by-component reset. For internal tables, it is the same as the REFRESH statement.
• Passing parameters (FORM / PERFORM, FUNCTION / CALL FUNCTION):
You can pass any data object using the USING and CHANGING parameters in the FORM / PERFORM statement, and by using
IMPORTING and EXPORTING parameters in the FUNCTION / CALL FUNCTION statements.
• Exporting and importing (EXPORT / IMPORT):
You can use the EXPORT/IMPORT interface to store any data object (in main memory) on the database.
Moreover, you can perform any of the following table operations on internal tables with any line type:
(APPEND, COLLECT, INSERT, MODIFY, DELETE, REFRESH, FREE, READ, SORT, LOOP, AT NEW / AT END OF, SUM) .
Strings
Strings - Fields with Variable Length
The elementary data type STRING is similar to data type C and refers to a
variable-length string. Accordingly, the elementary data type XSTRING is similar to data type X and refers to a variable-length byte sequence.
In contrast to a C or X field, the length of a string is not static but variable and adjusts itself to the current field content at runtime. Dynamic memory
management is used internally. Strings can have any length.
The initial value of a string is an empty string with length 0. A structure containing a string is seen as deep. A deep structure cannot be used like a C field. Strings can be displayed in the ABAP Debugger and used in the ABAP Dictionary.
It is not yet possible to use strings in screens or database tables. However, strings can be stored in database tables as clusters using EXPORT and transferred using
IMPORT.
Working with Strings
Typing Formal Parameters and Field Symbols
Formal parameters in FORM and FUNCTION, and field symbols
(FIELD-SYMBOLS) may be typed in ABAP. To do so, you use the ... TYPE dataType or
... LIKE dataObject additions to specify a type.
Typed formal parameters and field symbols make programs safer, and easier to understand and maintain. They also allow the ABAP generator to generate optimized intermediate code, thus improving the performance of your programs. If a formal paramter or field symbol is typed, the syntax check (if possible), or the runtime environment will check whether the actual parameter and formal
parameter are compatible. Typing with Complete Types
Compatibility in this context means that the two objects have the same technical type. Two types are compatible if they have exactly the same technical attributes. The technical attributes of a simple field are its elementary data type and the field length (in the case of type P fields, the number of decimal places as well). These are considered in the type check. The conversion exit and help ID are not. Note that the types STRING and C as well as XSTRING and X, are not compatible. In structures, the form of the structure is considered in addition to the component types. Two structures may have the same sequence of elementary components, but if that sequence is divided into substructures in different ways in the two
structures, they are not compatible in the sense of the technical ABAP type check. Two internal tables are compatible if their line types are compatible. The
OCCURS value is not considered in the type check.
Typing with Generic Types
A formal parameter or a field symbol can be typed incompletely by choosing a generic type which restricts the type of the actual parameter or runtime type to a subset of specific runtime types. Generic type specifications can be performed as follows.
The type ANY allows all generic and elementary types.
The following generic types make a restriction to the elementary runtime types. • SIMPLE: Allows all types which are permitted by the generic types
CLIKE, XSEQUENCE, or NUMERIC
• CLIKE: Allows all types which are permitted by the generic types CSEQUENCE and N as well as the elementary types D and T and also
structures which (directly or indirectly in substructures) contain only components of the types C, N, D, or T. In non-Unicode programs, the
generic type XSEQUENCE and all generic and elementary types contained therein are allowed additionally, and besides the components of the above structures, the types X and XSTRING are also allowed.
• CSEQUENCE: Allows all types permitted by the generic type C as well as
type STRING
• XSEQUENCE: Allows all types permitted by the generic type X as well as type XSTRING
• NUMERIC: Allows the generic type P, the elementary types I and F as well as the Data Dictionary types INT1 and INT2
• C, N, X: Allows all types C, N, X with a length between 1 and 32767 • P: Allows all types P with a length between 1 and 16 and with decimal
places from 0 to 14
The following generic types make a restriction to the types of internal tables. • ... TYPE TABLE allows you to mark a formal parameter or a field symbol
as a table parameter or table symbol for any internal table.
• ... TYPE [ANY|INDEX|STANDARD|SORTED|HASHED] TABLE is
used to accept tables of the table type specified which are compatible with the access hierarchy. The line type of the actual parameter can be chosen as required.
The following overview shows all ways of generic typing.
+---I,INT2,INT1 +---NUMERIC---+---P | +---F | | +---X +---SIMPLE---+---XSEQUENCE---+---XSTRING | | | +---CLIKE-+-CSEQUENCE---+---STRING ANY---+ | +---C | | | | +---N | +---+---D | +---T
| +---STRUC(C,N,D,T) |
+---TABLE
Other Comments on Typing with Generic Types
If a formal parameter or a field symbol is not typed or not typed completely, the formal parameter inherits the type attributes of the actual parameter. However, if a complete typing was made, the formal parameter always has the type attributes specified through typing.
In other words, this means that concerning the type attributes not considered by the type check (such as conversion exit and help ID) and which can therefore be different even for compatible actual and formal parameters,
• the actual parameter takes priority in case of missing or incomplete typing, and
• the formal parameter takes priority in case of complete typing.
Data Objects - Overview
Data ObjectsData objects are instances of data types, that is the specific data that a program handles at runtime. Each data object has a specific data type and appropriate memory assigned to it.
Data objects are instances of the data types subtree in the ABAP type hierarchy:
Data objects ---- elementary ---- static ---- C | | |-- N | | |-- D | | |-- T | | | | | |-- X | | | | | |-- P | | |-- I | | |-- F
| | | |-- dynamic ---- STRING | |-- XSTRING |-- reference variables | |-- complex ---- structures |-- internal tables
Data objects are defined statically with a data defining statement or dynamically using an operational statement. The prototype data defining statement is DATA. In addition, several other statements are available to define data objects with
additional specific properties.
In addition to the data objects declared in the program, several data objects are introduced automatically, for example, the system fields SY-... or the constant
SPACE. SUM(f) and CNT(f) within control level processing for extracts are also implicitly defined data objects.
The technical properties of data objects - that is, the field length, number of decimal places, and the data type - are always defined uniquely at runtime. There are two main types of data objects: Static data objects , where all technical properties must be defined in the declaration; and dynamic data objects, where the memory requirements and size are determined at runtime.
Dynamic data objects are the elementary data objects of types STRING and
XSTRING and internal tables.
• The length of character and byte strings is zero after their declaration; it changes during runtime according to the content assigned.
• Internal tables do not contain any lines after their declaration. They can have any number of lines and are filled dynamically at runtime.
All other data objects are static.
For further information refer to Data Objects in the SAP Library.
Visibility of Data Objects
Visibility of Data ObjectsData objects are always declared locally in a program. In terms of visibility, that is, their capacity to be addressed by name, a data object in ABAP can have local, global, or cross-program visibility.
• Locally-visible data objects are created within a procedure (FORM or FUNCTION) using a declarative statement, and are visible within that procedure after the point at which they are defined. A locally-visible object with the same name as a globally-visible object will obscure the global object within the procedure.
• Globally-visible data objects are created within a program, that is, anywhere but in a procedure, using a declarative statement other than
TABLES. They are visible within that program after the point at which
they are defined (as long as they are not obscured in a procedure by a local data object with the same name).
• A data object has cross-program visibility if it is defined using TABLES or DATA ... COMMON PART in a program. It is visible globally within the program from the point at which it is defined. In this respect, it is the same as a globally-visible object. However, the object is also placed in the cross-program memory that is shared at runtime by all programs that contain a corresponding data defintion.
Changing Data Objects
Variable and Constant Data ObjectsWith respect to the changeability of data contents,distinction can be made between variable and constant data objects:
• Variable data objects can change their value at runtime. All data objects
that are not defined by a statement defining data CONSTANTS are variable.
• Constant data objects always retain their initial value. They include the
literals and the constants declared by CONSTANTS
Named and Unnamed Data Objects
Named and Unnamed Data ObjectsWith regard to the symbolic addressability, you can distinguish between named and unnamed data objects:
• Variables and constants are named data objects and as such can be addressed symbolically by name regardless of the value.
• Literals represent themselves, i.e. they are fully defined as unnamed data
objects by their value.
Structure of Data Objects
Structure of Data ObjectsThe structure of a data object can be an • elementary field, a
• structure, or an • internal table.
Structures and internal tables are complex data obejcts. Since it is possible to combine structures and internal tables in any way, we can can also make a general distinction between different types of structures, internal tables, and data
structures.
A structure can be:
• A simple structure (as opposed to complex structures). A simple structure
is a structure with elementary components.
• A nested structure. A nested structure is a structure containing one or more
further structures.
• A deep structure. Deep structures are structures that contain an internal
table as a component, either directly or indirectly). An internal table can be:
• A simple internal table (as opposed to complex internal tables). A simple internal table has a simple structure.
• A dynamic array of elemntary types. This is a table with a non-structured
• A table with a deep line tpye. This is an internal table whose line type
contains one or more internal tables. Tables containing tables and tables with a deep structure are both examples of tables with a deep line type. Data structures (that is, structures and internal tables), can be distinguished as follows:
• Simple data structures (unlike complex data structures). These are simple structures or simple internal tables.
• Deep data structures. These are deep structures or internal tables.
Static and Dynamic Data Objects
Statically-Declared and Dynamically-Created Data Objects
There are two kinds of data objects: those that are declared statically,and those that are created dynamically.
• Any data object that you declare using a declarative statement is statically
declared, regardless of its visibility, validity and structure, whether or not it
can be changed, or addressed symbolically. Statically-declared data objects are administered when the program is generated.
• The lines in an internal table are created dynamically by the APPEND, COLLECT, and INSERT statements.
• Data objects with type STRING and XSTRING are also dynamic. They have initial length when the are declared; the memory that they use is assigned dynamically.
• ASSIGN LOCAL COPY OF f TO <fs> allows you to create data objects
dynamically on the stack.
Since the dynamic validity of local internal tables and dynamic stack extensions is restricted to the lifetime of the defining procedure, the corresponding resources are released automatically by the ABAP runtime system when the procedure ends. This means that you do not normally need to include memory management in your ABAP programs. However, you can release space occupied by an internal table using DELETE to delete individual lines, or REFRESH or FREE to delete a whole table.
Binding Data Objects to Formal Parameters and Field
Symbols
Binding of Data Objects to Formal Parameters and Field Symbols Currently data objects are bound to the formal parameters in subroutines,
function modules and methods at runtime. Bound formal parameters behave like locally visible variables with automatic validity.
Data objects are also bound dynamically to FIELD-SYMBOLS. Bound field symbols behave like local or global variables, depending on whether the field symbol has been defined locally or globally.
Validity Area For Data Objects in Events
Data Declarations in EventsWith "DATA X" in an event: When is X local, when is it global?
When you declare data (for example, using DATA), it depends on where in the program you define it as to whether it is global (can be addressed anywhere in the program), or whether the scope is restricted to the event in which you have placed it (local). Whilst it is clear that DATA X between FORM and ENDFORM or FUNCTION and ENDFUNCTION defines a variable X that is only recognized within the routine, the handling of this issue is not so clear with events. In this case, it depends whether the event is implemented internally as a FORM routine or not. Global: INITIALIZATION START-OF-SELECTION END-OF-SELECTION TOP-OF-PAGE... MODULE Local: AT SELECTION-SCREEN... GET dbtab... Example
Global data definition: INITIALIZATION. DATA X. START-OF-SELECTION. MOVE 'A' TO X. is syntactically correct. Example
Local data definition:
AT SELECTION-SCREEN. DATA X.
START-OF-SELECTION. MOVE 'A' TO X.
results in a syntax error because the field X is known only in connection with the event "AT SELECTION-SCREEN".
Alignment of Data Objects
Alignment of Data ObjectsYou cannot simply store fields at any addresses you want in main memory. For example, an ABAP field of the type I should normally have an address divisible by 4, a field of the type F an address divisible by 8, and so on. A field is considered to be aligned when it has an address corresponding to its data type.
For components of a structure, the distance of the component from the beginning of the structure is known as the offset of the component.
A structure is aligned if both the following are true:
• Its start address satisfies the strictest alignment requirements of its components and
• The offsets of all components satisfy the same type-specific divisibility requirements.
Normally, ABAP programmers do not have to be concerned about the correct alignment of fields or structures because this is set automatically on declaration. In the following cases, however, you must pay attention to alignment:
• When using ASSIGN to assign a new type to a field or structure • When using PERFORM to pass a field or structure as a parameter to a
FORM routine which expects a different type
• When an Open SQL command is used with a work area that has a different type to that of the database table.
Also, the offset of a structure component may not be the same as the total of the field lengths of the preceding components because some fields may be padded. If the alignment of a field or structure is insufficient, a runtime error occurs.
Byte Sequence
Byte Order
Binary representation of numbers
The binary representation of ABAP type I and type F numbers is hardware-specific. The byte order, which is pre-defined by the processor, is important in this respect. The byte order determines whether the highest-value byte ("big
endian" binary representation) or lowest-value byte ("little endian" binary
representation) is stored first. Example
You can represent the number 16909060 (in hexadecimal notation) as follows:
Endian Byte 1 Byte 2 Byte 3 Byte 4
big 0x01 0x02 0x03 0x04 little 0x04 0x03 0x02 0x01
The most common processors are Intel and DEC Alpha, both of which use little endian. Most other processors use big endian.
Binary representation of characters
Characters are represented in the Unicode format UCS-2 using 2-byte unsigned integer values. This means that this format depends on the number representation used by the hardware. Thus you must differentiate between UCS-2BE (big endian) and UCS-2LE (little endian).
