What are logical databases? What are the advantages/disadvantages of logical databases?
Ans :- A Logical Database is a hierarchical structure of tables. Use the GET statement to process Logical Databases.
LDB consists of logically related tables grouped together - used for reading and processing data.
Advantages
1. No need of programming for retrieval , meaning for data selection
2. Easy to use standard user interface, have check completeness of user input.
Disadvantages
1. Fast in case of lesser no. of tables But if the table is in the lowest level of hierarchy, all upper level tables should be read so performance is slower.
Preparation of the data records by the L.D.B and reading of the data records in the actual report are accomplished with the command pair.
Put and Get.
The three main elements of LDB are
Structure, Selections, Database Program.
Jun 17, 2008
A look on DATA DICTIONARY
DATA TYPES AND DATA OBJECT:
To work with data at runtime, you need to store it in the program at runtime and address it from your program. The system needs to know the type of the data (for example, character string, whole number, table consisting of name, currency amount, and date, and so on). A data object is a named memory area that is structured according to a particular data type . The type normally specifies all of the attributes of the data object. Using the name, you can access the contents, that is the data, directly. The name may be a compound name consisting of more than one single name.
You could regard a data type as being similar to the construction plans for a building. The plans could be used for more than one building, which would all have the same type, but you would still be able to tell them apart. Suppose the buildings were used for storage. You would find a particular item using the address of the building, and knowing on which floor, in which room, and in which shelf or bin it was stored. You would have to consider carefully when drawing up your plans the kinds of things you would want to store in your buildings.
The ABAP language is very flexible. Some of the attributes of a data type do not have to be specified until you use it to declare a data object, or, in some cases, not until runtime. It also allows you to use data objects that you have already declared or ABAP Dictionary objects as the basis for new types or data objects.
There are various places in the ABAP Workbench in which you can store and define data types:
ABAP Dictionary
The ABAP Dictionary contains 23 predefined data types, which serve as a basis for all other ABAP Dictionary objects (such as domains, data elements, data types, and so on). These ABAP Dictionary types are available for use globally throughout the system.
As well as the Dictionary objects used to access tables (tables, views, search helps, and so on), you can also (from Release 4.5) create global data types in the ABAP Dictionary.
Previously, the only way to define global data types was to use a type group. Type groups are still supported, but the concept is actually obsolete now that it is possible to define global data types in the ABAP Dictionary.
ABAP programs
Data types that you define in an ABAP program are local, that is, only valid within that program. You use the ten predefined ABAP data types as a basis for your own types.
Both global and local data types fit into the schematic diagram above. The names used above should make it easier for you to understand the following slides and the online documentation.
The technical attributes of an elementary field are defined by an elementary type .
A structure type consists of components.
A table type consists of a line type , access type , key definition, and key type .
In certain exceptional cases, types only desscribe part of the attributes of a data object. For example, a table type does not specify how many lines the table will have. This attribute is not set until runtime, and only affects that one data object.
You can nest types "deeply" to any level. That means:
A structured type can have components that are themselves structured or table types. This enables you to construct very complex data types. However, the smallest indivisible unit is always an elementary type.
The ABAP Dictionary contains a series of predefined data types to represent the external data types of the various database systems.
When you define a field with type CURR in the ABAP Dictionary, you must always link to a currency. You do this by specifying a field with the type CUKY. (When you create a list, you use the CURRENCY addition in the WRITE statement). The same applies to type QUAN, which must always link to a field with type UNIT.
Type FLTP is useful for calculations involving very large or very small numbers. This usually only occurs in scientific applications or when making estimates.
For business calculations, you should always use type DEC or QUAN. The arithmetic is the same as that to which you are used "on paper" - the system calculates precisely to the last decimal place.
A typical use for type NUMC is for postal code fields - fields in which only digits should be allowed, but with which you do not want to perform calculations. (It is, however, possible to use conversions and calculate with alpha-numeric data.) For further details about arithmetic and conversions, refer to the Statements unit.
Based on their underlying data type, some data objects are displayed according to formatting options (for example, country-specific date formats). Each user defines these formats in their user defaults.
All of these data types apart from string and rawstring are elementary types. For technical reasons, these are classified as nested types. This has consequences for certain uses, such as the INTO clause of a SELECT statement.
Data element
Data elements have a business meaning (field label, help text, and so on). Up to and including Release 4.0, it was only possible to specify the technical attributes of a data element by specifying a domain. Each domain had to have a predefined Dictionary type assigned to it. This is still possible. However, it is now possible to enter a predefined Dictionary type directly. If you want to ensure that the technical attributes of a group of data elements can only be changed centrally, you should continue to use domains.
As part of ABAP Objects, you can now designate a data element a reference type and declare global types for references to global classes or interfaces. Note that, in this case, the type of the data element is no longer elementary, but nested. The same applies when you use the predefined types string and rawstring.
Structure
Each component of a structure must have a name so that it can be addressed directly. For the type of a component you may specify a predefined Dictionary type, a data element, a structured type, or a table type. This allows you to construct nested data types. Note the consequences we have already mentioned with particular kinds of access. For example, if a structure contains a component with the type reference or string, you cannot use INTO CORRESPONDING FIELDS OF in a SELECT statement. Instead, you must list the components in the INTO clause.
The data type of an internal table is fully specified by its:
Line type
The line type defines the attributes of the individual fields. You can specify any ABAP data type.
Key definition
The key fields and their sequence determine the criteria by which the system identifies table lines.
Key type
You can define the key as either unique or non-unique . The uniqueness of the key must be compatible with the access type you have chosen for the table. If the key is unique, there can be no duplicate entrie s in the table.
Access type
Unlike database tables, the system assigns line numbers to certain kinds of internal tables. This means that you can use the index to access lines as well as the key. We sometimes use the term "table type " to refer to this.
We can also divide up internal table types into three kinds by their access type:
Standard tables.
In a standard table, you can access data using either the table index or the key. Since the key of a standard table always has to be non-unique for compatibility reasons, the system searches the whole table each time you access it using the key. Consequently, you should always use the index to access a standard table whenever possible.
Sorted tables.
In a sorted table, the system automatically stores the entries and inserts new entries sorted by the table key. The system uses a binary search on the table when you access it using the key. You can specify the key of a sorted table as unique. You will often use the key to access a sorted table, but it is also possible to use the index. Standard tables and sorted tables are generically known as index tables.
Hashed tables.
You can only access a hashed table using the key. There are certain conditions under which you can considerably reduce the access times to large tables by using a hashed table.
The key of a hashed table must always be unique.
You do not have to specify the access type fully. You can either omit it altogether, or specify it partially (index table). The table type is then generic, and, by omitting certain attributes, we can use it to specify the types of interface parameters.
To find out the access type of an internal table at runtime, use the statement DESCRIBE TABLE KIND .
The line type specifies the semantic and technical attributes of the individual fields in a line. As already mentioned, you can specify either another table type, a structured type, or an elementary type. If you only use an elementary type, the internal table will have a single column with no component name (unstructured table
Key definition
The default key consists of all character (alphanumeric) components of the line type that are not themselves table types. In this case, it would be empty (only possible with standard tables).
It is particularly useful to name the line type , that is, the whole line, as the key if the table type is unstructured.
You can also name key components and their sequence explicitly.
A final possibility is not to specify the key, leaving it generic instead.
Key type As well as defining the key as unique and non-unique , you can specify a generic key type by omitting the specificatio n.
Type F is useful for calculations involving very large or very small numbers. This usually only occurs in scientific applications or when making estimates.
For business calculations, you should always use type P. The arithmetic is the same as that to which you are used "on paper" - the system calcualtes precisely to the la st decimal place.
A typical use for type N is for postal code fields - fields in which only digits should be allowed, but with which you do not want to perform calculations. (It is, however, possible to use conversions and calculate with alpha-numeric data.) For further details about arithmetic and conversions, refer to the Statements unit.
Unlike type C, N, or X fields, the length of a string or hexadecimal string is not statically defined. Instead, it is variable, and, at runtime, will always take the length of its current contents. The memory is managed dynamically by the system. Strings and hexadecimal strings can have any length.
You cannot currently use STRING or XSTRING to specify the type of a screen field.
You can only define a new data type based on an existing type. Use the TYPE addition to refer to data types, that is, predefined ABAP types, user-defined local types, predefined ABAP Dictionary types, user-defined ABAP Dictionary types, or fields or entire lines from database tables. If you refer to an ABAP Dictionary type, changes to the global type are automatically passed on to your type. This ensures that your type is always compatible with the corresponding ABAP Dictionary object. Types that refer to the ABAP Dictionary also have the advantages of formatting options, field help, and possible entries help.
The underlying ABAP Dictionary data type is converted into the corresponding ABAP data type when the program is generated. For further information, refer to the ABAP syntax documentation for the TABLES statement.
If a global and a local data type both have the same name, the system uses the local type .
Use the LIKE addition to refer to the type of a data object that you have already declared. This also applies to the next slides.
Elementary types
The length specification after the type name for ABAP data types C, N, and X specifies the number of characters in the type. For type P fields, you can also set the number of decimal places. If you omit these specifications, the system uses the default values (refer to the chart under Predefined ABAP Types).
Structured type s Use the statements
TYPES BEGIN OF .
And TYPES END OF .
to enclose the list of components in your structure. Any type definitions may appear between the two statements. You can also construct nested data types.
To refer to the line type of a table type or an internal table, use the additions TYPE LINE OF or LIKE LINE OF respectively.
Table types Similarly to when you create table types in the ABAP Dictionary, you must specify various attributes here:
The line type after ... TABLE OF (as always, if you refer to a data type, use TYPE, if you refer to a data object that has already been declared, used LIKE);
The access type before TABLE OF ... (If you omit this, the system uses the default access type, which is standard. You can also specify a generic table type using INDEX or ANY.);
The key definition after the key type (to specify the default key, use the DEFAULT KEY addition); You can also specify fields from the (flat) line type and specify the sequence explicitly. If the table is unstructured, you can use the TABLE LINE addition);
The key type after ...WITH (UNIQUE or NON-UNIQUE).
If you omit the key specification entirely, the system uses the non-unique default key.
For information about the optional INITIAL SIZE addition, refer to the page Declaring Internal Tables.
We have not yet introduced reference types. These will be discussed in conjunction with field symbols and references.
Similarly to when you define data types, you must specify a type when you declare data objects. You can do this in one of two ways:
Either by referring to a data type (using the TYPE addition), or a data object in the program that has already been declared (using the LIKE addition). You can use exactly the same syntax variants in the DATA statement as when you declare local data types using the TYPES statement.
You can also construct a field, structure, or internal table directly in a DATA statement, without having to define your own data type first.
In most cases, you will want to change the value of data objects at runtime. They are therefore also known as variables. You can assign a starting value to a data object using the VALUE addition. If you do not, the system assigns it the initial value appropriate to its type (see the table under Predefined ABAP Types).
There are two further statements that you can use to declare special data objects:
STATICS declares local variables in a subroutine whose values are retained in subsequent subroutine calls instead of being initialized again. For further information, refer to the Subroutines uint.
CLASS-DATA, an ABAP Objects statement, allows you to declare static class attributes.
With the exception of the WITH HEADER LINE addition, the syntax for declaring internal table objects is exactly the same as that used to define table types or other kinds of data objects. The addition allows you to create an internal table with a header line . However, this is an obsolete programming technique, and you should consequently no longer use it. For more information about header lines, along with general information about internal tables, refer to the Internal Table Operations unit.
Dynamic table extension
Unlike arrays in other programming languages, the number of lines in an internal table is increased automatically by the ABAP runtime environment as required. You therefore do not have to worry about managing the size of the table, but only about inserting, reading, or deleting lines. This makes chained lists redundant in ABAP.
INITIAL SIZE addition
When you create an internal table, the system allocates 256 bytes to it. The system then allocates a block of 8 KB to the table when you first add data, followed by further 8KB blocks as required. If you are only expecting to place a few lines in your table, or are using nested internal tables, it may be worth restricting the first automatic extension using the addition INITIAL SIZE . You may do this either in the data object definition or in the type definition. is the maximum number of lines that you are expecting to put in the table. When the system first allocates memory, it allocates the product of and the length of the line. In the second step, it allocates twice that amount, and then in subsequent steps, it allocates between 12 and 16 KB.
Selection screens are a special kind of screen whose layout you program directly in the processing logic using ABAP statements . In an executable (type 1) program, there is a standard selection screen (screen number 1000). The definition of the standard selection screen does not require the statements that normally mark the beginning and end of a selection screen definition, neither does it require an explicit call. The following statements allow you to easily create screens on which the user can enter data.
PARAMETERS creates an input field on the selection screen with the type you specify and a variable in the program with the same name. You cannot use f, string, xstring, or references to specify the type.
SELECT-OPTIONS creates a pair of "from - to" fields on the screen, in which it is possible to enter sets of complex selections for a specified variable. The values that the user enters are stored in an internal table that the system creates automatically. The internal table has four fields sign, option, low, and high.
You can also create this kind of table using …{TYPE|LIKE} RANGE OF … . However, tables declared in this way are not linked to the selection screen.
For further information about these statements, refer to the courses BC405 (Techniques of List Processing and ABAP Query) and BC410 (Programming User Dialogs).
Constants and literals are fixed data objects - you cannot change their values at runtime.
You define constants using the ABAP keyword CONSTANTS. In it, you must use the VALUE addition to assign a value to your constant.
Recommendation:
Avoid using literals wherever possible. Use constants instead. Your programs will then be easier to maintain.
Literals allow you to specify a value directly in an ABAP statement. There are two kinds of literals - numeric literals and text literals. Text literals must always be enclosed in single quotes. Integers (including a minus sign if appropriate) can be represented as numeric literals. They are mapped to the data types i and p (based on the interval that each data type can represent).
Example :
DATA: result1 TYPE i, result2 LIKE result1.
result1 = -1000000000 / 300 * 3. "result1: 999.999-
result2 = -10000000000 / 300 * 3. "result2: 10.000.000-
A numeric literal can contain up to 31 digits.
All other values (decimal and floating point numbers, strings, and so on) must be given as text literals. The system converts the data type if necessary.
A text literal can contain up to 255 characters.
If you want a single quote to appear in a text literal, you must use two single quotes in order for it to be interpreted as part of the literal and not the closing single quote.
Text symbols are a special form of text literals. You can create a set of text symbols for any program. These can be used for output in various ways. The advantage of text symbols over normal text literals is that they can be translated. Furthermore, text elements are stored separately from the program source code, making your program easier to understand.
Text symbols are often used to create lists that are not language-specific. You can also use them to assign texts dynamically to screen objects. (Static text elements for screen objects are a special case, and can be translated).
You can display text symbols in two different ways using the WRITE statement:
WRITE text-. (where can be any three-character ID).
WRITE ''(). (where can be any three-character ID). In this
case, is displayed if there is a text for it in the current logon language. If there is not, the default text is displayed.
When you use screens, the system automatically transports field contents from the processing logic to the screen and back, but only where screen fields and ABAP fields have the same names.
Restriction:
If you use screen fields with a reference to the ABAP Dictionary (Get from Dictionary function in the Screen Painter), you must use the TABLES statement to declare a data object with the same name as the ABAP Dictionary object in order for the field transport to work. Structures you declare like this are often referred to as work areas.
There are numerous advantages to using an ABAP Dictionary reference: Dictionary objects normally include foreign key checks, field help, possible entries, and the necessary error dialogs. Consequently you can catch inconsistent data as soon as the user enters it and before you even leave the screen.
If you program your own field checks, the field contents must already have been transported to the program. If you forget to reset the field when a check fails, an unwanted value may remain in the work area. You also face the same danger if you are not sure whether work areas are shared by more than one program.
To avoid these dangers, you should regard TABLES work areas as an interface between the screen and program, and only use them in this context. They provide data for the screen at the end of the PBO event, and receive it again when the values are transported from the screen.
Logical databases are special ABAP programs that you can attach to an executable (type 1) program. They read data from the database and pass it to the executable program. Because the task of reading the data has been passed to the logical database, your own ABAP program becomes considerably simpler.
The logical database passes the data to your program using interface work areas that you declare using the NODES statement. The statement creates a variable that refers to the data type in the ABAP Dictionary with the same name.
The data is passed to your program record by record. Each time the logical database makes a record available to your program, the corresponding GET or GET LATE event is triggered. In your program, you can code the relevant event blocks.
You can determine the type of the data record returned by the logical database using the TYPE addition However, you are restricted to types that are supported by the logical database.
The data object SPACE is a constant with type C and length 1. It contains a single space.
The system automatically creates a structure called sy for each program, based on the ABAP Dictionary structure syst. The individual components of the structure are known as system fields .
They contain values that inform you about the current state of the system. The values are updated automatically by the ABAP runtime environment.
You can access individual system fields using the notation sy-.
System fields are variables, so you can change them in your programs. However, you should only do this in cases where it is explicitly recommended in the documentation (for example, navigating between list levels by manipulating sy-lsind). In all other cases, you should only read the contents of system fields, since by changing them you might overwrite information that is important for subsequent steps in the program.
The online documentation contains a list of all system fields with notes on their use. You can also display the structure syst in the ABAP Dictionary.
You declare field symbols using the FIELD-SYMBOLS <> statement. The brackets (<>) are part of the syntax.
Field symbols allow you symbolic access to an existing data object. All of the changes that you make to the field symbol are applied to the data object assigned to it. If the field symbol is not typed (TYPE ANY), it adopts the type of the data object. By specifying a type for the field symbol, you can ensure that only compatible objects are assigned to it.
Field symbols are similar to dereferenced pointers .
You use the ASSIGN statement to assign a data object to the field symbol <>. To lift a type restriction, use the CASTING addition. The data object is then interpreted as though it had the data type of the field symbol. You can also do this with untyped field symbols using the CASTING TYPE addition.
Use the expression <> IS ASSIGNED to find out whether the fie ld symbol <> is assigned to a field.
The statement UNASSIGN <>. sets the field symbol <> so that it points to nothing.
The logical expression <> IS ASSIGNED is then false.
An untyped field symbol that does not have a data object assigned to it behaves (for compatibility reasons) like a constant with type C and length 1.
The statement TYPES TYPE REF TO data. *) defines a reference type to a data object. DATA... defines the corresponding reference itself. Such a reference is a field in which an address can be stored.
The GET REFERENCE OF INTO statement writes the address of the data object (already declared) into the reference variable. In other words, the reference points to the data object in memory.
Thus ABAP uses reference semantics (changes apply to the address) as well as value semantics, as used in field symbols (where changes apply to the data objects). However, in ABAP, reference semantics is restricted to assignments.
The dereferencing operator ->* in the ASSIGN statement allows you to assign the data object to which the reference points to a field symbol. You can then access the value of the data object.
You can create a data object with a specified type at runtime using the CREATE DATA
statement. This data object has no name, but the reference points to its address.
You can use type casting dynamically when you assign a data object to a field symbol. The graphic presents an example of this.
The name of the database table is not known until runtime (and consequently, neither is the line type).
Since you cannot specify a dynamic INTO clause in the SELECT statement, the system writes the data records into the long character field line.
The assignment to field symbol and the type casting then make it possible to access the field as though it were a flat structure. All type attributes are inherited from the database table. (You can also refer to the line type of an ABAP Dictionary object using the TYPE addition.)
If you knew the component names, you could display the fields directly using
WRITE -... .
However, you will not normally know the names of the components. In this case, you must use the ASSIGN COMPONENT variant, in which the components of the structure are assigned one-by-one to the field symbol and then displayed. When the loop runs out of components, the program reads the next data record.
Problem
The address of line must satisfy the same address rules as a table structure (address must be divisible by four with no remainder). You can force this by declaring an integer field dummy directly before declaring line. (Integers are always stored at addresses that are divisible by four.)
Unlike conventional data objects, you can specify the type of a data object created at runtime dynamically. The above example is a slightly modified version of the example on the previous page.
This time, the idea is the create the data object for the INTO clause dynamically at runtime . In this case, the type is already known (you have entered the table name), and there are no more alignment problems. The statement ASSIGN d_ref->* to assigns the data object to the field symbol. The data type of the table is inherited by the field symbol, so type casting is no longer necessary.
Instead of using a long character field, you can now write the data record into the data object with the same type to which the reference d_ref is pointing, by using the field symbol .
You will sometimes need to find out the attributes of a data object at runtime , especially when you use field symbols and references. The DESCRIBE FIELD statement returns various type attributes of variables.
Caution:
If you query the length of a field with type string or xstring, the system does not return the length of the string. Instead, it returns the length of the string reference, which is always eight bytes. To find out the length of the string, use the OUTPUT-LENGTH addition.
The statement DESCRIBE TABLE LINES returns the number of lines in an internal table.
Since the introduction of ABAP Objects, there is now a system called the RTTI concept (Run Time Type Information) that you can use to find out type attributes at runtime. It is based on system classes. The concept includes all ABAP types, and so covers all of the functions of the statements DESCRIBE FIELD and DESCRIBE TABLE.
To work with data at runtime, you need to store it in the program at runtime and address it from your program. The system needs to know the type of the data (for example, character string, whole number, table consisting of name, currency amount, and date, and so on). A data object is a named memory area that is structured according to a particular data type . The type normally specifies all of the attributes of the data object. Using the name, you can access the contents, that is the data, directly. The name may be a compound name consisting of more than one single name.
You could regard a data type as being similar to the construction plans for a building. The plans could be used for more than one building, which would all have the same type, but you would still be able to tell them apart. Suppose the buildings were used for storage. You would find a particular item using the address of the building, and knowing on which floor, in which room, and in which shelf or bin it was stored. You would have to consider carefully when drawing up your plans the kinds of things you would want to store in your buildings.
The ABAP language is very flexible. Some of the attributes of a data type do not have to be specified until you use it to declare a data object, or, in some cases, not until runtime. It also allows you to use data objects that you have already declared or ABAP Dictionary objects as the basis for new types or data objects.
There are various places in the ABAP Workbench in which you can store and define data types:
ABAP Dictionary
The ABAP Dictionary contains 23 predefined data types, which serve as a basis for all other ABAP Dictionary objects (such as domains, data elements, data types, and so on). These ABAP Dictionary types are available for use globally throughout the system.
As well as the Dictionary objects used to access tables (tables, views, search helps, and so on), you can also (from Release 4.5) create global data types in the ABAP Dictionary.
Previously, the only way to define global data types was to use a type group. Type groups are still supported, but the concept is actually obsolete now that it is possible to define global data types in the ABAP Dictionary.
ABAP programs
Data types that you define in an ABAP program are local, that is, only valid within that program. You use the ten predefined ABAP data types as a basis for your own types.
Both global and local data types fit into the schematic diagram above. The names used above should make it easier for you to understand the following slides and the online documentation.
The technical attributes of an elementary field are defined by an elementary type .
A structure type consists of components.
A table type consists of a line type , access type , key definition, and key type .
In certain exceptional cases, types only desscribe part of the attributes of a data object. For example, a table type does not specify how many lines the table will have. This attribute is not set until runtime, and only affects that one data object.
You can nest types "deeply" to any level. That means:
A structured type can have components that are themselves structured or table types. This enables you to construct very complex data types. However, the smallest indivisible unit is always an elementary type.
The ABAP Dictionary contains a series of predefined data types to represent the external data types of the various database systems.
When you define a field with type CURR in the ABAP Dictionary, you must always link to a currency. You do this by specifying a field with the type CUKY. (When you create a list, you use the CURRENCY addition in the WRITE statement). The same applies to type QUAN, which must always link to a field with type UNIT.
Type FLTP is useful for calculations involving very large or very small numbers. This usually only occurs in scientific applications or when making estimates.
For business calculations, you should always use type DEC or QUAN. The arithmetic is the same as that to which you are used "on paper" - the system calculates precisely to the last decimal place.
A typical use for type NUMC is for postal code fields - fields in which only digits should be allowed, but with which you do not want to perform calculations. (It is, however, possible to use conversions and calculate with alpha-numeric data.) For further details about arithmetic and conversions, refer to the Statements unit.
Based on their underlying data type, some data objects are displayed according to formatting options (for example, country-specific date formats). Each user defines these formats in their user defaults.
All of these data types apart from string and rawstring are elementary types. For technical reasons, these are classified as nested types. This has consequences for certain uses, such as the INTO clause of a SELECT statement.
Data element
Data elements have a business meaning (field label, help text, and so on). Up to and including Release 4.0, it was only possible to specify the technical attributes of a data element by specifying a domain. Each domain had to have a predefined Dictionary type assigned to it. This is still possible. However, it is now possible to enter a predefined Dictionary type directly. If you want to ensure that the technical attributes of a group of data elements can only be changed centrally, you should continue to use domains.
As part of ABAP Objects, you can now designate a data element a reference type and declare global types for references to global classes or interfaces. Note that, in this case, the type of the data element is no longer elementary, but nested. The same applies when you use the predefined types string and rawstring.
Structure
Each component of a structure must have a name so that it can be addressed directly. For the type of a component you may specify a predefined Dictionary type, a data element, a structured type, or a table type. This allows you to construct nested data types. Note the consequences we have already mentioned with particular kinds of access. For example, if a structure contains a component with the type reference or string, you cannot use INTO CORRESPONDING FIELDS OF in a SELECT statement. Instead, you must list the components in the INTO clause.
The data type of an internal table is fully specified by its:
Line type
The line type defines the attributes of the individual fields. You can specify any ABAP data type.
Key definition
The key fields and their sequence determine the criteria by which the system identifies table lines.
Key type
You can define the key as either unique or non-unique . The uniqueness of the key must be compatible with the access type you have chosen for the table. If the key is unique, there can be no duplicate entrie s in the table.
Access type
Unlike database tables, the system assigns line numbers to certain kinds of internal tables. This means that you can use the index to access lines as well as the key. We sometimes use the term "table type " to refer to this.
We can also divide up internal table types into three kinds by their access type:
Standard tables.
In a standard table, you can access data using either the table index or the key. Since the key of a standard table always has to be non-unique for compatibility reasons, the system searches the whole table each time you access it using the key. Consequently, you should always use the index to access a standard table whenever possible.
Sorted tables.
In a sorted table, the system automatically stores the entries and inserts new entries sorted by the table key. The system uses a binary search on the table when you access it using the key. You can specify the key of a sorted table as unique. You will often use the key to access a sorted table, but it is also possible to use the index. Standard tables and sorted tables are generically known as index tables.
Hashed tables.
You can only access a hashed table using the key. There are certain conditions under which you can considerably reduce the access times to large tables by using a hashed table.
The key of a hashed table must always be unique.
You do not have to specify the access type fully. You can either omit it altogether, or specify it partially (index table). The table type is then generic, and, by omitting certain attributes, we can use it to specify the types of interface parameters.
To find out the access type of an internal table at runtime, use the statement DESCRIBE TABLE KIND .
The line type specifies the semantic and technical attributes of the individual fields in a line. As already mentioned, you can specify either another table type, a structured type, or an elementary type. If you only use an elementary type, the internal table will have a single column with no component name (unstructured table
Key definition
The default key consists of all character (alphanumeric) components of the line type that are not themselves table types. In this case, it would be empty (only possible with standard tables).
It is particularly useful to name the line type , that is, the whole line, as the key if the table type is unstructured.
You can also name key components and their sequence explicitly.
A final possibility is not to specify the key, leaving it generic instead.
Key type As well as defining the key as unique and non-unique , you can specify a generic key type by omitting the specificatio n.
Type F is useful for calculations involving very large or very small numbers. This usually only occurs in scientific applications or when making estimates.
For business calculations, you should always use type P. The arithmetic is the same as that to which you are used "on paper" - the system calcualtes precisely to the la st decimal place.
A typical use for type N is for postal code fields - fields in which only digits should be allowed, but with which you do not want to perform calculations. (It is, however, possible to use conversions and calculate with alpha-numeric data.) For further details about arithmetic and conversions, refer to the Statements unit.
Unlike type C, N, or X fields, the length of a string or hexadecimal string is not statically defined. Instead, it is variable, and, at runtime, will always take the length of its current contents. The memory is managed dynamically by the system. Strings and hexadecimal strings can have any length.
You cannot currently use STRING or XSTRING to specify the type of a screen field.
You can only define a new data type based on an existing type. Use the TYPE addition to refer to data types, that is, predefined ABAP types, user-defined local types, predefined ABAP Dictionary types, user-defined ABAP Dictionary types, or fields or entire lines from database tables. If you refer to an ABAP Dictionary type, changes to the global type are automatically passed on to your type. This ensures that your type is always compatible with the corresponding ABAP Dictionary object. Types that refer to the ABAP Dictionary also have the advantages of formatting options, field help, and possible entries help.
The underlying ABAP Dictionary data type is converted into the corresponding ABAP data type when the program is generated. For further information, refer to the ABAP syntax documentation for the TABLES statement.
If a global and a local data type both have the same name, the system uses the local type .
Use the LIKE addition to refer to the type of a data object that you have already declared. This also applies to the next slides.
Elementary types
The length specification after the type name for ABAP data types C, N, and X specifies the number of characters in the type. For type P fields, you can also set the number of decimal places. If you omit these specifications, the system uses the default values (refer to the chart under Predefined ABAP Types).
Structured type s Use the statements
TYPES BEGIN OF .
And TYPES END OF .
to enclose the list of components in your structure. Any type definitions may appear between the two statements. You can also construct nested data types.
To refer to the line type of a table type or an internal table, use the additions TYPE LINE OF or LIKE LINE OF respectively.
Table types Similarly to when you create table types in the ABAP Dictionary, you must specify various attributes here:
The line type after ... TABLE OF (as always, if you refer to a data type, use TYPE, if you refer to a data object that has already been declared, used LIKE);
The access type before TABLE OF ... (If you omit this, the system uses the default access type, which is standard. You can also specify a generic table type using INDEX or ANY.);
The key definition after the key type (to specify the default key, use the DEFAULT KEY addition); You can also specify fields from the (flat) line type and specify the sequence explicitly. If the table is unstructured, you can use the TABLE LINE addition);
The key type after ...WITH (UNIQUE or NON-UNIQUE).
If you omit the key specification entirely, the system uses the non-unique default key.
For information about the optional INITIAL SIZE addition, refer to the page Declaring Internal Tables.
We have not yet introduced reference types. These will be discussed in conjunction with field symbols and references.
Similarly to when you define data types, you must specify a type when you declare data objects. You can do this in one of two ways:
Either by referring to a data type (using the TYPE addition), or a data object in the program that has already been declared (using the LIKE addition). You can use exactly the same syntax variants in the DATA statement as when you declare local data types using the TYPES statement.
You can also construct a field, structure, or internal table directly in a DATA statement, without having to define your own data type first.
In most cases, you will want to change the value of data objects at runtime. They are therefore also known as variables. You can assign a starting value to a data object using the VALUE addition. If you do not, the system assigns it the initial value appropriate to its type (see the table under Predefined ABAP Types).
There are two further statements that you can use to declare special data objects:
STATICS declares local variables in a subroutine whose values are retained in subsequent subroutine calls instead of being initialized again. For further information, refer to the Subroutines uint.
CLASS-DATA, an ABAP Objects statement, allows you to declare static class attributes.
With the exception of the WITH HEADER LINE addition, the syntax for declaring internal table objects is exactly the same as that used to define table types or other kinds of data objects. The addition allows you to create an internal table with a header line . However, this is an obsolete programming technique, and you should consequently no longer use it. For more information about header lines, along with general information about internal tables, refer to the Internal Table Operations unit.
Dynamic table extension
Unlike arrays in other programming languages, the number of lines in an internal table is increased automatically by the ABAP runtime environment as required. You therefore do not have to worry about managing the size of the table, but only about inserting, reading, or deleting lines. This makes chained lists redundant in ABAP.
INITIAL SIZE addition
When you create an internal table, the system allocates 256 bytes to it. The system then allocates a block of 8 KB to the table when you first add data, followed by further 8KB blocks as required. If you are only expecting to place a few lines in your table, or are using nested internal tables, it may be worth restricting the first automatic extension using the addition INITIAL SIZE . You may do this either in the data object definition or in the type definition. is the maximum number of lines that you are expecting to put in the table. When the system first allocates memory, it allocates the product of and the length of the line. In the second step, it allocates twice that amount, and then in subsequent steps, it allocates between 12 and 16 KB.
Selection screens are a special kind of screen whose layout you program directly in the processing logic using ABAP statements . In an executable (type 1) program, there is a standard selection screen (screen number 1000). The definition of the standard selection screen does not require the statements that normally mark the beginning and end of a selection screen definition, neither does it require an explicit call. The following statements allow you to easily create screens on which the user can enter data.
PARAMETERS creates an input field on the selection screen with the type you specify and a variable in the program with the same name. You cannot use f, string, xstring, or references to specify the type.
SELECT-OPTIONS creates a pair of "from - to" fields on the screen, in which it is possible to enter sets of complex selections for a specified variable. The values that the user enters are stored in an internal table that the system creates automatically. The internal table has four fields sign, option, low, and high.
You can also create this kind of table using …{TYPE|LIKE} RANGE OF … . However, tables declared in this way are not linked to the selection screen.
For further information about these statements, refer to the courses BC405 (Techniques of List Processing and ABAP Query) and BC410 (Programming User Dialogs).
Constants and literals are fixed data objects - you cannot change their values at runtime.
You define constants using the ABAP keyword CONSTANTS. In it, you must use the VALUE addition to assign a value to your constant.
Recommendation:
Avoid using literals wherever possible. Use constants instead. Your programs will then be easier to maintain.
Literals allow you to specify a value directly in an ABAP statement. There are two kinds of literals - numeric literals and text literals. Text literals must always be enclosed in single quotes. Integers (including a minus sign if appropriate) can be represented as numeric literals. They are mapped to the data types i and p (based on the interval that each data type can represent).
Example :
DATA: result1 TYPE i, result2 LIKE result1.
result1 = -1000000000 / 300 * 3. "result1: 999.999-
result2 = -10000000000 / 300 * 3. "result2: 10.000.000-
A numeric literal can contain up to 31 digits.
All other values (decimal and floating point numbers, strings, and so on) must be given as text literals. The system converts the data type if necessary.
A text literal can contain up to 255 characters.
If you want a single quote to appear in a text literal, you must use two single quotes in order for it to be interpreted as part of the literal and not the closing single quote.
Text symbols are a special form of text literals. You can create a set of text symbols for any program. These can be used for output in various ways. The advantage of text symbols over normal text literals is that they can be translated. Furthermore, text elements are stored separately from the program source code, making your program easier to understand.
Text symbols are often used to create lists that are not language-specific. You can also use them to assign texts dynamically to screen objects. (Static text elements for screen objects are a special case, and can be translated).
You can display text symbols in two different ways using the WRITE statement:
WRITE text-. (where can be any three-character ID).
WRITE ''(). (where can be any three-character ID). In this
case, is displayed if there is a text for it in the current logon language. If there is not, the default text is displayed.
When you use screens, the system automatically transports field contents from the processing logic to the screen and back, but only where screen fields and ABAP fields have the same names.
Restriction:
If you use screen fields with a reference to the ABAP Dictionary (Get from Dictionary function in the Screen Painter), you must use the TABLES statement to declare a data object with the same name as the ABAP Dictionary object in order for the field transport to work. Structures you declare like this are often referred to as work areas.
There are numerous advantages to using an ABAP Dictionary reference: Dictionary objects normally include foreign key checks, field help, possible entries, and the necessary error dialogs. Consequently you can catch inconsistent data as soon as the user enters it and before you even leave the screen.
If you program your own field checks, the field contents must already have been transported to the program. If you forget to reset the field when a check fails, an unwanted value may remain in the work area. You also face the same danger if you are not sure whether work areas are shared by more than one program.
To avoid these dangers, you should regard TABLES work areas as an interface between the screen and program, and only use them in this context. They provide data for the screen at the end of the PBO event, and receive it again when the values are transported from the screen.
Logical databases are special ABAP programs that you can attach to an executable (type 1) program. They read data from the database and pass it to the executable program. Because the task of reading the data has been passed to the logical database, your own ABAP program becomes considerably simpler.
The logical database passes the data to your program using interface work areas that you declare using the NODES statement. The statement creates a variable that refers to the data type in the ABAP Dictionary with the same name.
The data is passed to your program record by record. Each time the logical database makes a record available to your program, the corresponding GET or GET LATE event is triggered. In your program, you can code the relevant event blocks.
You can determine the type of the data record returned by the logical database using the TYPE addition However, you are restricted to types that are supported by the logical database.
The data object SPACE is a constant with type C and length 1. It contains a single space.
The system automatically creates a structure called sy for each program, based on the ABAP Dictionary structure syst. The individual components of the structure are known as system fields .
They contain values that inform you about the current state of the system. The values are updated automatically by the ABAP runtime environment.
You can access individual system fields using the notation sy-.
System fields are variables, so you can change them in your programs. However, you should only do this in cases where it is explicitly recommended in the documentation (for example, navigating between list levels by manipulating sy-lsind). In all other cases, you should only read the contents of system fields, since by changing them you might overwrite information that is important for subsequent steps in the program.
The online documentation contains a list of all system fields with notes on their use. You can also display the structure syst in the ABAP Dictionary.
You declare field symbols using the FIELD-SYMBOLS <> statement. The brackets (<>) are part of the syntax.
Field symbols allow you symbolic access to an existing data object. All of the changes that you make to the field symbol are applied to the data object assigned to it. If the field symbol is not typed (TYPE ANY), it adopts the type of the data object. By specifying a type for the field symbol, you can ensure that only compatible objects are assigned to it.
Field symbols are similar to dereferenced pointers .
You use the ASSIGN statement to assign a data object to the field symbol <>. To lift a type restriction, use the CASTING addition. The data object is then interpreted as though it had the data type of the field symbol. You can also do this with untyped field symbols using the CASTING TYPE addition.
Use the expression <> IS ASSIGNED to find out whether the fie ld symbol <> is assigned to a field.
The statement UNASSIGN <>. sets the field symbol <> so that it points to nothing.
The logical expression <> IS ASSIGNED is then false.
An untyped field symbol that does not have a data object assigned to it behaves (for compatibility reasons) like a constant with type C and length 1.
The statement TYPES TYPE REF TO data. *) defines a reference type to a data object. DATA... defines the corresponding reference itself. Such a reference is a field in which an address can be stored.
The GET REFERENCE OF INTO statement writes the address of the data object (already declared) into the reference variable. In other words, the reference points to the data object in memory.
Thus ABAP uses reference semantics (changes apply to the address) as well as value semantics, as used in field symbols (where changes apply to the data objects). However, in ABAP, reference semantics is restricted to assignments.
The dereferencing operator ->* in the ASSIGN statement allows you to assign the data object to which the reference points to a field symbol. You can then access the value of the data object.
You can create a data object with a specified type at runtime using the CREATE DATA
statement. This data object has no name, but the reference points to its address.
You can use type casting dynamically when you assign a data object to a field symbol. The graphic presents an example of this.
The name of the database table is not known until runtime (and consequently, neither is the line type).
Since you cannot specify a dynamic INTO clause in the SELECT statement, the system writes the data records into the long character field line.
The assignment to field symbol and the type casting then make it possible to access the field as though it were a flat structure. All type attributes are inherited from the database table. (You can also refer to the line type of an ABAP Dictionary object using the TYPE addition.)
If you knew the component names, you could display the fields directly using
WRITE -... .
However, you will not normally know the names of the components. In this case, you must use the ASSIGN COMPONENT variant, in which the components of the structure are assigned one-by-one to the field symbol and then displayed. When the loop runs out of components, the program reads the next data record.
Problem
The address of line must satisfy the same address rules as a table structure (address must be divisible by four with no remainder). You can force this by declaring an integer field dummy directly before declaring line. (Integers are always stored at addresses that are divisible by four.)
Unlike conventional data objects, you can specify the type of a data object created at runtime dynamically. The above example is a slightly modified version of the example on the previous page.
This time, the idea is the create the data object for the INTO clause dynamically at runtime . In this case, the type is already known (you have entered the table name), and there are no more alignment problems. The statement ASSIGN d_ref->* to assigns the data object to the field symbol. The data type of the table is inherited by the field symbol, so type casting is no longer necessary.
Instead of using a long character field, you can now write the data record into the data object with the same type to which the reference d_ref is pointing, by using the field symbol .
You will sometimes need to find out the attributes of a data object at runtime , especially when you use field symbols and references. The DESCRIBE FIELD statement returns various type attributes of variables.
Caution:
If you query the length of a field with type string or xstring, the system does not return the length of the string. Instead, it returns the length of the string reference, which is always eight bytes. To find out the length of the string, use the OUTPUT-LENGTH addition.
The statement DESCRIBE TABLE LINES returns the number of lines in an internal table.
Since the introduction of ABAP Objects, there is now a system called the RTTI concept (Run Time Type Information) that you can use to find out type attributes at runtime. It is based on system classes. The concept includes all ABAP types, and so covers all of the functions of the statements DESCRIBE FIELD and DESCRIBE TABLE.
TYPES OF TABLE IN SAP
Choosing a Table Type
The table type (and particularly the access method) that you will use depends on how the typical internal table operations will be most frequently executed.
Standard tables
This is the most appropriate type if you are going to address the individual table entries using the index. Index access is the quickest possible access. You should fill a standard table by appending lines (ABAP APPEND statement), and read, modify and delete entries by specifying the index (INDEX option with the relevant ABAP command). The access time for a standard table increases in a linear relationship with the number of table entries. If you need key access, standard tables are particularly useful if you can fill and process the table in separate steps. For example, you could fill the table by appending entries, and then sort it. If you use the binary search option with key access, the response time is logarithmically proportional to the number of table entries.
Sorted tables
This is the most appropriate type if you need a table which is sorted as you fill it. You fill sorted tables using the INSERT statement. Entries are inserted according to the sort sequence defined through the table key. Any illegal entries are recognized as soon as you try to add them to the table. The response time for key access is logarithmically proportional to the number of table entries, since the system always uses a binary search. Sorted tables are particularly useful for partially sequential processing in a LOOP if you specify the beginning of the table key in the WHERE condition.
Hashed tables
This is the most appropriate type for any table where the main operation is key access. You cannot access a hashed table using its index. The response time for key access remains constant, regardless of the number of table entries. Like database tables, hashed tables always have a unique key. Hashed tables are useful if you want to construct and use an internal table which resembles a database table or for processing large amounts of data.
Table type
The table type determines how ABAP will access individual table entries. Internal tables can be divided into three types:
Standard tables have an internal linear index. From a particular size upwards, the indexes of internal tables are administered as trees. In this case, the index administration overhead increases in logarithmic and not linear relation to the number of lines. The system can access records either by using the table index or the key. The response time for key access is proportional to the number of entries in the table. The key of a standard table is always non-unique. You cannot specify a unique key. This means that standard tables can always be filled very quickly, since the system does not have to check whether there are already existing entries.
Sorted tables are always saved sorted by the key. They also have an internal index. The system can access records either by using the table index or the key. The response time for key access is logarithmically proportional to the number of table entries, since the system uses a binary search. The key of a sorted table can be either unique or non-unique. When you define the table, you must specify whether the key is to be unique or not. Standard tables and sorted tables are known generically as index tables.
Hashed tables have no linear index. You can only access a hashed table using its key. The response time is independent of the number of table entries, and is constant, since the system access the table entries using a hash algorithm. The key of a hashed table must be unique. When you define the table, you must specify the key as UNIQUE.
Concept of VIEWS in SAP
Views :Data about an application object is often distributed on several tables. By defining a :view, you can define an application-dependent view that combines this data. The structure of such a view is defined by specifying the tables and fields used in the view. Fields that are not required can be hidden, thereby minimizing interfaces. A view can be used in ABAP programs for data selection.
The data of a view is derived from one or more tables, but not stored physically. The simplest form of deriving data is to mask out one or more fields from a base table (projection) or to include only certain entries of a base table in the view (selection). More complicated views can comprise several base tables, the individual tables being linked with a relational join operation.
The base tables of the view must be selected in the first step of a view definition. In the second step, these tables must be linked by defining the join conditions. It is also possible to use the join condition from a foreign key defined between the tables .
In the third step, you must select the fields of the base tables to be used in the view. Selection conditions that restrict the records in the view can be formulated in the fourth step.
Four different view types are supported. These differ in the way in which the view is implemented and in the methods permitted for accessing the view data.
· Database views implemented with an equivalent view on the database.
· Projection views used to hide fields of a table (only projection).
· Help views used as selection method in search helps
· Maintenance views permit you to maintain the data distributed on several tables for one application object at one time.
Database views implement an inner join. The other view types implement an outer join
The join conditions for database views can be formulated using equality relationships between any base fields. The join conditions for the other view types must be obtained from existing foreign keys. Tables therefore can only be combined in a maintenance view or help view if they are linked to one another with foreign keys.
The maintenance status whether you can only read data with the view or whether you can also insert and change data with it.
Database Views :
Data about an application object is often distributed on several database tables. A database view provides an application-specific view on such distributed data.
Database views are defined in the ABAP Dictionary. A database view is automatically created in the underlying database when it is activated.
Application programs can access the data of a database view using the database interface. You can access the data in ABAP programs with both OPEN SQL and NATIVE SQL. However, the data is actually selected in the database. Since the join operation is executed in the database in this case, you can minimize the number of database accesses in this way. Database views implement an inner join (see Inner and Outer Join )
If the database view only contains a single table, the maintenance status can be used to determine if data records can also be inserted with the view. If the database view contains more than one table, you can only read the data.
Database views should be created if want to select logically connected data from different tables simultaneously. Selection with a database view is generally faster than access to individual tables. When selecting with views, you should also ensure that there are suitable indexes on the tables contained in the view.
Since a database view is implemented in the database, a database view may only contain transparent tables.
The technical settings of a database view control whether the view data should be buffered.
Projection Views :
Projection views are used to hide fields of a table. This can minimize interfaces; for example when you access the database, you only read and write the field contents actually needed.
A projection view contains exactly one table. You cannot define selection conditions for projection views.
There is no corresponding object in the database for a projection view. The R/3 System maps the access to a projection view to the corresponding access to its base table. You can also access pooled tables and cluster tables with a projection view.
The maintenance status of the view controls how the data of the table can be accessed with the projection view.
Help Views:
You have to create a help view if a view with outer join is needed as selection method of a search help
The selection method of a search help is either a table or a view. If you have to select data from several tables for the search help, you should generally use a database view as selection method. However, a database view always implements an inner join. If you need a view with outer join for the data selection, you have to use a help view as selection method.
All the tables included in a help view must be linked with foreign keys. Only foreign keys that have certain attributes can be used here. The first table to be inserted in the help view is called the primary table of the help view. The tables added to this primary table with foreign keys are called secondary tables.
The functionality of a help view has changed significantly between Release 3.0 and Release 4.0. In Release 3.0, a help view was automatically displayed for the input help (F4 help) for all the fields that were checked against the primary table of the help view. This is no longer the case in Release 4.0.
As of Release 4.0, you must explicitly create a search help that must be linked with the fields for which it is offered (see Linking Search Helps with Screen Fields ).
Existing help views are automatically migrated to search helps when you upgrade to a release higher than 4.0.
A help view implements an outer join, i.e. all the contents of the primary table of the help view are always displayed. You therefore should not formulate a selection condition for fields in one of the secondary tables of the help view. If records of these secondary tables cannot be read as a result of this selection condition, the contents of the corresponding fields of the secondary table are displayed with initial value.
Search Helps :
The input help (F4 help) is a standard function of the R/3 System. The user can display the list of all possible input values for a screen field with the input help. The possible input values can be enhanced with further information. This is meaningful especially when the field requires the input of a formal key.
Standard Input Help Process
A user calls an input help with the following steps (some steps can be omitted, depending on the definition of the input help):
The user starts the input help to display the possible input values for a field (search field) in a screen template.
The system offers the user a number of possible search paths. The user selects one of these search paths. Each search path offers a number of restrictions to limit the number of possible input values. These values are offered in a Dialog box for value restriction when the search path is selected.
The user enters restrictions if required and then starts the search.
The system determines the values that satisfy the entered restrictions (hits) and displays them as a list (hit list).
The user selects the most suitable line from the hit list by double-clicking. The value of the search field is returned to the screen template (possibly together with other values).
Steps 2 and 3 are omitted if there is only a single search path available. In this case the dialog box for the value selection is offered immediately. You can also output the hit list directly after starting the input help. Steps 2 to 4 are omitted in this case.
Function of a Search Help
This standard process can be completely defined by creating a search help in the ABAP Dictionary. This search help only has to be assigned to the screen fields in which they should be available.
There are two types of search help:
· Elementary search helps describe a search path. The elementary search help must define where the data of the hit list should be read from (selection method), how the exchange of values between the screen template and selection method is implemented (interface of the search help) and how the online input help should be defined (online behavior of the search help).
· Collective search helpscombine several elementary search helps. A collective search help thus can offer several alternative search paths.
Maintenance Views :
Maintenance views offer easy ways to maintain complex application objects.
Data distributed on several tables often forms a logical unit, for example an application object, for the user. You want to be able to display, modify and create the data of such an application object together. Normally the user is not interested in the technical implementation of the application object, that is in the distribution of the data on several tables.
A maintenance view permits you to maintain the data of an application object together. The data is automatically distributed in the underlying database tables. The maintenance status determines which accesses to the data of the underlying tables are possible with the maintenance view.
All the tables in a maintenance view must be linked with foreign keys, that is the join conditions for maintenance views are always derived from the foreign key
cannot directly enter the join conditions as for database views.
There are some restrictions for the attributes of the foreign keys with which the tables in a maintenance view can be linked .
A standardized table maintenance transaction is provided (SM30), permitting you to maintain the data from the base tables of a maintenance view together.
Maintenance mechanisms, like screens and processing programs, must be created from the view definition with the transaction Generate Table View (SE54). This makes it possible to create easy-to-use maintenance interfaces in a simple manner.
LOCK OBJECT CONCEPT IN SAP
If several users are competing to access the same resource or resources, you need to find a way of synchronizing the access in order to protect the consistency of your data.
Example: In a flight booking system, you would need to check whether seats were still free before making a reservation. You also need a guarantee that critical data (the number of free seats in this case) cannot be changed while you are working with the program.
Locks are a way of coordinating competing accesses to a resource. Each user requests a lock before accessing critical data.
It is important to release the lock as soon as possible, so as not to hinder other users unnecessarily.
Whenever you make direct changes to data on the database in a transaction, the database system sets corresponding locks.
The database management system (DBMS) physically locks the table entries that you want to change (INSERT; UPDATE, MODIFY), and those that you read from the database and intend to change (SELECT SINGLE FROM FOR UPDATE). Other users who want to access the locked record or records must wait until the physical lock has been released. In such a case, the ABAP program waits until the lock has been released again.
At the end of the database transaction, the database releases all of the locks that it has set during the transaction.
In the R/3 System, this means that each database lock is released when a new screen is displayed, since a change of screen triggers an implicit database commits.
To keep a lock set through a series of screens (from the dialog program to the update program), the R/3 System has a global lock table at the application server level, which you can use to set logical locks for table entries.
One application server contains this lock table and a special enqueue work process, which administers all requests for logical locks in the R/3 System. All logical lock requests of the R/3 System run using this work process.
You can also use logical locks to "lock" table entries that do not yet exist on the database (inserting new lines). You cannot do this with physical database locks.
For further information, see the ABAP Editor Keyword documentation for the term Locking.
Logical locks are generated when an entry is written in the lock table. You use function modules to do this.
You can only set a lock if the relevant table entry is not already locked.
The SAP transaction receives information on the success of a lock request from a return code sent via the EXCEPTION interface of the function module. In other words, the control is returned to the program using the function module. The ABAP program does not need to wait.
The SAP transaction can react appropriately by analyzing the return code.
Another user cannot gain access to work with the same table entries that are already locked.
Depending on the bundling technique in use for database updates), the program must delete the lock entries it generated using a lock module, or have them deleted indirectly (see unit Organizing Database Updates).
If the user terminates the program that generated the lock entries (usually a dialog program), the locks are released automatically (implicitly). You can do this by entering /n in the command field, or with the statements LEAVE PROGRAM, LEAVE TO TRANSACTION, and 'A' or 'X'
Messages.
When you call an ENQUEUE function module, the dialog program tries to generate a lock entry.
The export parameters identify the table entry (or entries) that you want to lock.
The program that generates the locks (usually dialog program) analyzes the return code for lock requests and reacts accordingly.
If the lock could not be set; you should normally output an error message.
At the end of the dialog program, you can use the corresponding DEQUEUE function module to delete the entries from the lock table.
DEQUEUE function modules have no exceptions. If you try to release an entry that is not locked, this has no effect.
If you want to release all of the locks that you have set, at the end of your dialog program, you can use the function module DEQUEUE_ALL.
The lock table contains the lock arguments for each table (for lock arguments, see the following slide).
To display the lock table, use transaction SM12.
The entries in the lock table are standard. Locks are always set using the values of the key fields in a table. These form the lock argument.
You pass the values for the lock argument to the lock modules via their interface (function module IMPORT parameters).
If you fail to set any of these parameters, the system interprets it generically, that is, the lock is set for all table lines that meet the criteria specified in the other parameters. The client parameter is an exception to this rule, where the default client SY-MANDT applies.
Lock entries must be assigned to a lock mode.
There are three different lock modes:
Mode 'E' for write locks: This is set if you want to write data to the database (change, create, or delete).
Mode 'S' for read locks: This is set if you want to ensure that the data, which you are reading from the database in your program, is not changed by other users while the program is running. You do not want to change the data itself in your program.
Mode 'X' for write locks: Like mode 'E', mode 'X' is used for writing data to the database. The technical difference between mode 'X' and mode 'E' is that locks of mode 'X' are not accumulated while a program is being executed. (For further details, see the following pages).
If someone tries to lock the same data record again with a second program (different user), the various lock modes take effect as follows:
Write locks ('E' or 'X') mean that any lock attempts from other users are refused, irrespective of the mode in which the lock is attempted.
If a data record is locked in mode 'S' (shared), further locks in mode 'S' may be set by other users.
Lock attempts in other lock modes ('E' or 'X') are refused.
If you want to try to lock a data record more than once while a program is running (for example using a function module that you call up, which sets locks itself), the lock system reacts in the following way:
Mode 'E' write locks are not refused. Instead, a cumulative counter is incremented. The same applies to read locks (mode 'S').
If a data record is locked in mode 'E', a lock request generates a second lock, which is marked as a read lock.
If a data record is locked in mode 'S' and no further read locks are set by other users, a lock attempt in mode 'E' is possible. This generates a second entry in the lock table (for mode 'E').
If a data record is locked in mode 'X', all further lock requests are refused.
If you want to ensure that you are reading up-to-date data in your program (with the intention of changing and returning this to the database), you should use the following procedure for lock requests and database accesses in your program:
First, lock the data that you want to edit.
Then read the current data from the database.
In the next step, process (change) the data in your program and write this to the database.
In the final step, release the locks that you set at the beginning.
This procedure ensures that your changes run fully with lock protection and that you only read data that has been changed consistently by other programs (provided that these also use the SAP lock concept and follow the procedure described here).
Lock modules are created for lock objects and not tables.
Lock objects are maintained in the dictionary. Customer lock objects must begin with "EY" or "EZ".
A lock object is a logical object composed of a list of tables that are linked by foreign key
Relationships. Lock modules are generated for these objects and enable common lock entries to be set for all tables contained in the lock object. This allows combinations of table entries to be locked.
Example: A lock object that contains the tables SFLIGHT and SBOOK enables a flight with its bookings to be locked.
The list of tables for a lock object consists of a primary table. Further table entries are referred to as secondary tables. Only tables with foreign key relationships to the primary table can be used as secondary tables.
With lock objects, you can assign different names for the parameters that describe the fields of the lock arguments for the lock modules. The names of the table fields (key fields of the tables) are proposed by the system.
You can specify the lock mode (a write lock 'E' or 'X' or a read lock 'S') for each table. These function as default values for the lock modules.
After you have assigned tables and default lock modes, lock objects must be generated.
When you activate a lock object, the system generates an ENQUEUE and a DEQUEUE function module.
These have the names ENQUEUE_ and DEQUEUE_ respectively.
If you want to ensure that you are reading current data in your program (with the intention of changing and returning this to the database), you should use the following procedure in your program for lock requests and database accesses:
1. Lock the data that you want to edit.
2. Read the current data from the database.
3. Process (change) the data in your program and write this to the database.
4. Release the locks that you set at the beginning.
This procedure ensures that your changes run fully with lock protection and that you only read data, which has been changed consistently by other programs (with the restriction that these are also using the SAP lock concept and following the procedure described).
If you change the order of the four steps to Read -> Lock -> Change -> Unlock, you run the risk that the data read by your program will not be up to date. Your program can read data before another user's program writes changes to the database. This means that a user of your program will make decisions for entries that are not based on up-to-date data from the database. For this reason, you should always follow the recommended procedure.
Requesting a lock from a program is a communication step with lock administration. The
Communication step requires a certain time interval. If your program sets locks for several objects, this interval occurs more than once.
By using so-called local lock containers, you can reduce these communication intervals with lock administration. To do so, collect the required lock requests of your program and send them together to lock administration.
The locks (delayed execution) can be collected when the lock modules are called. For this purpose, qualify the IMPORT parameter_collect with 'X'. The data transferred via the lock module interface is then registered in a list (lock container) as a lock request that needs to be executed.
The lock container can be terminated using the FLUSH_ENQUEUE function module and sent to lock administration.
When the lock orders of a lock container can be executed, the lock container is deleted.
If one of the locks in a container cannot be set, the function module FLUSH_ENQUEUE triggers the exception FOREIGN_LOCK. In this case, none of the registered lock requests is executed. The registered locks remain in the lock container.
You can delete the contents of an existing lock container with the function module
RESET_ENQUEUE.
The specified function modules have release status internally-released.
Example: In a flight booking system, you would need to check whether seats were still free before making a reservation. You also need a guarantee that critical data (the number of free seats in this case) cannot be changed while you are working with the program.
Locks are a way of coordinating competing accesses to a resource. Each user requests a lock before accessing critical data.
It is important to release the lock as soon as possible, so as not to hinder other users unnecessarily.
Whenever you make direct changes to data on the database in a transaction, the database system sets corresponding locks.
The database management system (DBMS) physically locks the table entries that you want to change (INSERT; UPDATE, MODIFY), and those that you read from the database and intend to change (SELECT SINGLE
Open SQL vs Native SQL
Question : What is Open SQL vs Native SQL?
Question :What does an EXEC SQL statement do in ABAP? What is the disadvantage of using it?
If you write a business application, there is always a database on backend. So SAP R/3 uses a database too. It is a
special database? No. SAP uses standard databases like Oracle, IBM DB2, MS SQL Server, etc. If you have a database on backend, it is inevitable that you must use SQL. SAP uses SQL to select, insert and update data inside database. However, the problem is that if you use different databases, your code whatever it is whether ABAP or not, SQL can vary. In that situation although programmers tend to use Standard SQL which is valid for all databases, the problems sometimes occur to switch one database to different database. What I am trying to say is SAP had invented a new way to solve this problem: Open SQL
Open SQL
Open SQL consists of a set of ABAP statements that perform operation on central database in the R/3 System. The results of the operations and any error messages are independent of the database system in use. Open SQL thus provides a uniform syntax and semantics for all of database systems supported by SAP. ABAP programs that only use Open SQL statements will work in any SAP R/3 System, regardless of the database system in use. Open SQL statements can work with database tables that have been created in the ABAP Dictionary.
The method actually is simple that when a programmer writes an ABAP program with Open SQL statements, the kernel SAP programs convert Open SQL statements to real / native SQL statements for database in use. So like that write once, run for all databases and even for all operating systems. Like Java’s “Write Once. Run Anywhere“. Think about Java, even the Java uses the same principal that is Java Virtual Machine which looks like SAP’s kernel programs. Right? 
Can we say SAP did “Write Once. Run Anywhere” before Java?
Open SQL contains the following keywords:
- SELECT - Reads data from database tables.
- INSERT - Adds lines to database tables.
- UPDATE - Changes the contents of lines of database tables.
- MODIFY - Inserts lines into database tables or changes the contents of existing lines.
- DELETE - Delete lines from database tables.
- OPEN CURSOR, FETCH, CLOSE CURSOR - Reads lines of database tables using the cursor.
All Open SQL statements fill the following two system fields with return codes:
- SY-SUBRC
After every Open SQL statement, the system field SY-SUBRC contains 0 if the operation was successful, a value other than 0 if not. - SY-DBCNT
After an OPEN SQL statement, the system field SY-DBCNT contains the number of database lines processed.
Native SQL
Native SQL is real SQL for database in use. It means beside OPEN SQL, if you need you can use the native SQL for databases. Native SQL allows you to use database-specific SQL statements in an ABAP program. This means that you can use database tables that are not administered by the ABAP Dictionary, and therefore integrate data that is not part of the R/3 System.
As a rule, an ABAP program containing database-specific SQL statements will not run under different database systems. If your program will be used on more than one database platform, only use Open SQL statements.
I have never used Native SQL in my experiences more than 6 years for ABAP programming. I tried it, you can be sure it works. All ABAP programs in SAP R/3 System have been written with Open SQL. But I sometimes encountered Native SQL statements in original ABAP programs. I think if you have a different database instant in the same database, you can use Native SQL statement to connect and do operation on this database instant. Let me clarify this a little bit. Let’s assume you have an SAP R/3 system that uses Oracle database instant ORC1. You have an other application, even it uses the same database Oracle, but as normally different database instant ORC2. So like data inside ABAP program, you can use Native SQL statements to connect ORC2, non-SAP database instant, to integrate SAP R/3 and non-SAP system. It is kind of an integration activity.
If you create a table by using database tools, without ABAP Dictionary, you are not able to use Open SQL to reach this table. You just can use Native SQL to do that.
Native SQL statements bypass the R/3 database interface. There is no table logging, and no synchronization with the database buffer on the application server. For this reason, you should, wherever possible, use Open SQL to change database tables declared in the ABAP Dictionary. In particular, tables declared in the ABAP Dictionary that contain log columns with types LCHR and LRAW should only be addressed using Open SQL, since the columns contain extra, database-specific length information for the column. Native SQL does not take this information into account, and may therefore produce incorrect results. Furthermore, Native SQL does not support automatic client handling. Instead, you must treat client fields like any other.
To ensure that transactions in the R/3 System are consistent, you should not use any transaction control statements (COMMIT, ROLLBACK WORK), or any statements that set transaction parameters (isolation level…) using Native SQL.
Using Native SQL, you can
- Transfer values from ABAP fields to the database
- Read data from the database and process it in ABAP programs.
Native SQL works without the administrative data about database tables stored in the ABAP Dictionary. Consequently, it cannot perform all of the consistency check used in Open SQL. This places a larger degree responsibility on application developers to work with ABAP fields of the correct type. You should always ensure that the ABAP data type and the type of database column are identical.
Native SQL Advantages and Disadvantages - EXEC SQL statement
Advantages
- Tables are not declared in ABAP Dictionary can be accessed. (e.g. Tables belonging to sys or system user of Oracle, etc.)
- To use some of the special features supported by the database-specific SQL. (e.g. Passing hints to Oracle optimizer.)
Disadvanteges
- No syntax check is performed whatever is written between EXEC and ENDEXEC.
- ABAP program containing database-specific SQL statements will not run under different database systems.
- There is no automatic client handling for client dependent tables.
- Care has to be taken during migration to higher versions.
ASAP Methodology
Enterprise application software has to cover a broad spectrum of functionality, yet be configured flexibly enough to meet specific requirements, which can vary enormously. SAP’s answers to this challenge are AcceleratedSAP and the R/3 Business Engineer, providing a comprehensive solution for implementing R/3 quickly, easily, and according to your own needs even during productive operation.
Born out of the need to cost effectively configure R/3 to order, AcceleratedSAP and the Business R/3 Engineer support custom configuration of R/3. You can tailor the R/3 components, functions and organizational structures to your needs, hiding and/or deactivating those functions that are not required.
Fig. 1: The R/3 Business Engineer Complements ASAP
AcceleratedSAP (ASAP) is SAP's standard implementation methodology. It contains the Roadmap, a step-by-step guide that incorporates experience from many years of implementing R/3. Along with that, AcceleratedSAP contains a multitude of tools, accelerators and useful information to assist all team members in implementing R/3. Quality checks are incorporated at the end of each phase to easily monitor deliverables and critical success factors. ASAP is delivered as a PC-based package, so that - if required - an implementation project can begin prior to having an R/3 System installed.
The R/3 Business Engineer contains a set of configuration and implementation tools which enable you or your consultants to define and configure R/3 and also to adapt an existing configuration to new needs or changed circumstances. The Business Engineer is resident to R/3.
So that its customers can implement R/3 as quickly as possible, SAP has standardized the implementation procedure, simplified the way functions are presented and reduced the technical complexity of implementation.
AcceleratedSAP and the Business Engineer help you configure R/3 according to your own needs using proven, industry-specific business scenarios and processes. Whether implementing new processes in your enterprise or restructuring old ones, R/3 can release the full potential of change for you. AcceleratedSAP and the Business Engineer help you determine which of R/3’s proven processes are most suited to your business, and then help you configure to meet your specific needs. The benefit is obvious: Restructuring enterprise processes in the R/3 System leads to a rapid and efficient production startup, meaning a faster return on investment.
By simplifying configuration, ASAP and the Business Engineer make the power of R/3 more accessible, helping companies to lower their dependence on expensive specialists or outside consultants. The user-friendliness of ASAP and the Business Engineer make them particularly suitable for the following groups:
- Business professionals who need to discuss, prototype and design their business blueprint (enterprise model)
- IS departments of large enterprises who need to customize R/3 applications more efficiently and more rapidly
- Small and medium-sized companies previously wary of implementing R/3 because of the perceived scale of such projects
- Consultants and SAP partners looking for an efficient way of offering their customers configure-to-order or wishing to develop R/3-based solutions for niche markets
Together, AcceleratedSAP and the Business Engineer empower you to manage cost, time and quality without compromising on implementation requirements. Some of the features offered are:
q Reduced implementation times and faster return on investment through structured planning and preconfiguration
- Intuitive understanding of the wide range of functions offered by R/3
- Process optimization using proven scenarios, processes and value chains, illustrating clearly the software’s capabilities and offering practical help when you configure the R/3 System.
q High quality installations through comprehensive procedural guidelines
q Optimizing business processes using SAP Business Workflow, via process monitoring and automation of procedures
- Continuous, dynamic adjustment and optimization of R/3 applications
- The capability to copy configured areas, for example, by transferring existing settings to new organizational units.
AcceleratedSAP and the Business Engineer are designed for openness and new platforms, using HTML-based documentation. Compatibility with many third-party modeling tools and software packages, for example, Microsoft Excel, is ensured.
Embarking on an implementation project requires a lot of careful thought beforehand. You need to think about what you want to accomplish, the optimum sequence, and the business cases that are best suited to your needs. But SAP has already done a lot of the thinking for you and packaged its findings in the following tools. They are then described in more detail in the following chapters organized according to the corresponding AcceleratedSAP phases.
- AcceleratedSAP (ASAP): A comprehensive solution for the introduction of the R/3 System in your enterprise. ASAP and most of its tools can be used independently of an R/3 installation.
The tools available for AcceleratedSAP are:
- The Project Estimator, an internal SAP tool which enables SAP consultants to accurately gauge the required resources, the costs and the time frame of implementation. The Project Estimator takes into account the project scope and several project and risk factors.
- The Concept Check Tool, a tool enabling you to carry out quality checks on the project preparation, technical infrastructure and R/3 configuration settings. This is done mainly during the first two implementation phases of the R/3 project. In this way you are alerted to potential data volume and configuration conflicts that could lead to performance issues if not addressed.
- The Implementation Assistant: The ASAP navigation tool that accompanies you through the five phases of implementation down to the task level. It includes a description and a detailed "how-to" for each task in the Roadmap. Along with that, many tools, templates and documents are hyperlinked to the task. The Implementation Assistant contains the following elements:
- ASAP Implementation Roadmap and Project Plan. The Roadmap contains the five phases, from which you can drill down into work packages, activities and tasks. The Project Plan contains three components, a budget plan, a resource plan and a work plan. These are explained in more detail in the next chapter.
The ASAP Roadmap is the successor of the R/3-based Procedure Model, which was used until Rel. 3.1 in R/3 implementation projects.
- Knowledge Corner, containing tips and tricks for configuration from consultants, detailed documentation on SAP’s implementation services, information on technical tools, as well as simplification guidebooks and R/3 Customizing wizards.
- Question and Answer Database (Q&Adb). Using the R/3 Reference Model structure, the Q&Adb is used to assist in gathering requirements for business processes, conversions, reports, interfaces, enhancements and authorizations. The database provides useful questionnaires to help you define the process needs and also serves as a repository for all this information. Since it is a database, it allows for flexible reporting. The business requirements generated from the Q&Adb are collectively known as the Business Blueprint.
- Business Process Master List, to manage configuration, testing and the creation of end user documentation. The Business Process Master List is linked to pre-written Business Process Procedures (BPPs), detailled end-user documentation for R/3 transactions.
- Issues Database: supporting project management, this database supports the entering, monitoring and managing of issues that come up during the project.
- R/3 Business Engineer: The implementation tools for the high-quality configuration of the R/3 System are:
- R/3 Reference Model: Comprehensive graphical process flows describing the R/3 functionality from different points of view. It contains scenarios, processes and functions, as well as components. The R/3 Reference Model can be viewed using SAP's Business Navigator and the Business Navigator Web, or using third-party modeling tools available from modeling partners.
- Implementation Guide (IMG): Used to configure all system parameters for the business processes in R/3. It contains project management functionality and a menu-driven view of all R/3 Customizing activities. Every activity can be documented in detail, and responsibilities and statuses can be assigned.
- Preconfigured systems:
- Preconfigured US and Canadian clients: Provides a head start on baseline configuration. It includes a preconfigured US/Canadian chart of accounts, print forms, account determination, units of measure, etc. The predefined test sequences that are included can be a starting point for integration testing.
- Preconfigured industry systems: A number of complete preconfigured clients consisting of an industry-specific model and preconfigured business processes for the needs of a particular industry in R/3 are available. For more information on preconfigured systems, see the description of Phase 2, Business Blueprint or the information on the IDES System in this chapter.
Continuous Business Engineering
In today’s fast-moving, ever-changing business climate, companies are in a constant state of flux and their mission-critical applications must adapt and evolve at the same speed. If software cannot grow with the needs of a company, the company will quickly find itself in a straightjacket.
Furthermore, an ERP application needs to let you move forward fast, knowing that you can roll back changes without downtime.
An enterprise's organizational structure and the corresponding R/3 implementation created using the Business Engineer are not "set in concrete", they can be modified at any time. Examples of possible changes, which can be made rapidly include the following:
- Addition or removal of entities within the organization structure (for example, business units, production plants, warehouses, etc.)
- Introduction of new staff, promotion, reallocation of work tasks, and maintenance of authorization profiles
- Changes to the reporting or cost/profit center structure
- New and concurrent currencies
- Accommodation of changed legal requirements (for example, new tax rates, new employment legislation)
- Activation or deactivation of R/3 functions
- Optimization of business processes
- Support for new and multiple versions of R/3
In addition, SAP offers a range of services if you want support for some of these changes, for example, conversion services to support mergers and acquisitions. Standard Euro services are a further example of the available services.
AcceleratedSAP and R/3 Business Engineer take the hassle out of implementation procedures and change management. Modifications can be made at any time, and the compatibility of changes can be verified with other configuration decisions, thus supporting their smooth, trouble-free introduction into the productive system.
Subscribe to:
Posts (Atom)
-
Category : ABAP Programming Error Runtime Errors: READ_REPORT_LINE_TOO_LONG Except.: CX_SY_READ_SRC_LINE_TOO_LONG Detail explanati... -
Data Class The data class determines the physical area of the database (tablespace) in which the table is created. You set the data...
-
Function module that will take any internal table as input, convert in to XLS format and send out emails with the attachment. Add the...