Solved: Internal Tables

Former Member · ‎2007 Apr 18

hi all,

1. what is the difference between Headerline and Workarea of the table?

2. waht are the differeces between standard, sort and hased tables?

3. how can we use field-symbols and what are the advantages?

please explain in detail

Thanks,

Satish

Former Member · ‎2007 Apr 18

Hi,

Header line and Workarea of the table are same which will hold a single record of the table at run time.

The following are the table types used in SAP :

I. Transparent tables (BKPF, VBAK, VBAP, KNA1, COEP)

Allows secondary indexes (SE11->Display Table->Indexes)

Can be buffered (SE11->Display Table->technical settings) Heavily updated tables should not be buffered.

II. Pool Tables (match codes, look up tables)

Should be accessed via primary key or

Should be buffered (SE11->Display Table->technical settings)

No secondary indexes

Select * is Ok because all columns retrieved anyway

III. Cluster Tables (BSEG,BSEC)

Should be accessed via primary key - very fast retrieval otherwise very slow

No secondary indexes

Select * is Ok because all columns retrieved anyway. Performing an operation on multiple rows is more efficient than single row operations. Therefore you still want to select into an internal table. If many rows are being selected into the internal table, you might still like to retrieve specific columns to cut down on the memory required.

Statistical SQL functions (SUM, AVG, MIN, MAX, etc) not supported

Can not be buffered

IV. Buffered Tables (includes both Transparent & Pool Tables)

While buffering database tables in program memory (SELECT into internal table) is generally a good idea for performance, it is not always necessary. Some tables are already buffered in memory. These are mostly configuration tables. If a table is already buffered, then a select statement against it is very fast. To determine if a table is buffered, choose the 'technical settings' soft button from the data dictionary display of a table (SE12). Pool tables should all be buffered.

Tables Documentation

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/25c1f5d1-0901-0010-d495-e96d02a0...

FIELD Symbols

Field Symbols

Field symbols are placeholders or symbolic names for other fields. They do not physically reserve space for a field, but point to its contents. A field symbol cam point to any data object. The data object to which a field symbol points is assigned to it after it has been declared in the program.

Whenever you address a field symbol in a program, you are addressing the field that is assigned to the field symbol. After successful assignment, there is no difference in ABAP whether you reference the field symbol or the field itself. You must assign a field to each field symbol before you can address the latter in programs.

Field symbols are similar to dereferenced pointers in C (that is, pointers to which the content operator * is applied). However, the only real equivalent of pointers in ABAP, that is, variables that contain a memory address (reference) and that can be used without the contents operator, are reference variables in ABAP Objects.

All operations programmed with field symbols are applied to the field assigned to it. For example, a MOVE statement between two field symbols moves the contents of the field assigned to the first field symbol to the field assigned to the second field symbol. The field symbols themselves point to the same fields after the MOVE statement as they did before.

You can create field symbols either without or with type specifications. If you do not specify a type, the field symbol inherits all of the technical attributes of the field assigned to it. If you do specify a type, the system checks the compatibility of the field symbol and the field you are assigning to it during the ASSIGN statement.

Field symbols provide greater flexibility when you address data objects:

If you want to process sections of fields, you can specify the offset and length of the field dynamically.

You can assign one field symbol to another, which allows you to address parts of fields.

Assignments to field symbols may extend beyond field boundaries. This allows you to address regular sequences of fields in memory efficiently.

You can also force a field symbol to take different technical attributes from those of the field assigned to it.

The flexibility of field symbols provides elegant solutions to certain problems. On the other hand, it does mean that errors can easily occur. Since fields are not assigned to field symbols until runtime, the effectiveness of syntax and security checks is very limited for operations involving field symbols. This can lead to runtime errors or incorrect data assignments.

While runtime errors indicate an obvious problem, incorrect data assignments are dangerous because they can be very difficult to detect. For this reason, you should only use field symbols if you cannot achieve the same result using other ABAP statements.

For example, you may want to process part of a string where the offset and length depend on the contents of the field. You could use field symbols in this case. However, since the MOVE statement also supports variable offset and length specifications, you should use it instead. The MOVE statement (with your own auxiliary variables if required) is much safer than using field symbols, since it cannot address memory beyond the boundary of a field. However, field symbols may improve performance in some cases.

check the below links u will get the answers for your questions

http://help.sap.com/saphelp_nw04/helpdata/en/fc/eb3860358411d1829f0000e829fbfe/content.htm

http://www.sts.tu-harburg.de/teaching/sap_r3/ABAP4/field_sy.htm

http://searchsap.techtarget.com/tip/1,289483,sid21_gci920484,00.html

Syntax Diagram

FIELD-SYMBOLS

Basic form

FIELD-SYMBOLS <fs>.

Extras:

1. ... TYPE type

2. ... TYPE REF TO cif

3. ... TYPE REF TO DATA

4. ... TYPE LINE OF type

5. ... LIKE s

6. ... LIKE LINE OF s

7. ... TYPE tabkind

8. ... STRUCTURE s DEFAULT wa

The syntax check performed in an ABAP Objects context is stricter than in other ABAP areas. See Cannot Use Untyped Field Symbols ad Cannot Use Field Symbols as Components of Classes.

Effect

This statement declares a symbolic field called <fs>. At runtime, you can assign a concrete field to the field symbol using ASSIGN. All operations performed with the field symbol then directly affect the field assigned to it.

You can only use one of the additions.

Example

Output aircraft type from the table SFLIGHT using a field symbol:

FIELD-SYMBOLS <PT> TYPE ANY.

DATA SFLIGHT_WA TYPE SFLIGHT.

...

ASSIGN SFLIGHT_WA-PLANETYPE TO <PT>.

WRITE <PT>.

Addition 1

... TYPE type

Addition 2

... TYPE REF TO cif

Addition 3

... TYPE REF TO DATA

Addition 4

... TYPE LINE OF type

Addition 5

... LIKE s

Addition 6

... LIKE LINE OF s

Addition 7

... TYPE tabkind

Effect

You can define the type of the field symbol using additions 2 to 7 (just as you can for FORM parameters (compare Defining the Type of Subroutine Parameters). When you use the ASSIGN statement, the system carries out the same type checks as for USING parameters of FORMs.

This addition is not allowed in an ABAP Objects context. See Cannot Use Obsolete Casting for FIELD SYMBOLS.

In some cases, the syntax rules that apply to Unicode programs are different than those for non-Unicode programs. See Defining Types Using STRUCTURE.

Effect

Assigns any (internal) field string or structure to the field symbol from the ABAP Dictionary (s). All fields of the structure can be addressed by name: <fs>-fieldname. The structured field symbol points initially to the work area wa specified after DEFAULT.

The work area wa must be at least as long as the structure s. If s contains fields of the type I or F, wa should have the structure s or at least begin in that way, since otherwise alignment problems may occur.

Example

Address components of the flight bookings table SBOOK using a field symbol:

DATA SBOOK_WA LIKE SBOOK.

FIELD-SYMBOLS <SB> STRUCTURE SBOOK

DEFAULT SBOOK_WA.

...

WRITE: <SB>-BOOKID, <SB>-FLDATE.

Additional help

Declaring Field Symbols

reward if useful

regards,

ANJI

Former Member · ‎2007 Apr 18

Hi Satish,

Internal tables

Internal tables provide a means of taking data from a fixed structure and storing it in working memory in ABAP. The data is stored line by line in memory, and each line has the same structure. In ABAP, internal tables fulfill the function of arrays. Since they are dynamic data objects, they save the programmer the task of dynamic memory management in his or her programs. You should use internal tables whenever you want to process a dataset with a fixed structure within a program. A particularly important use for internal tables is for storing and formatting data from a database table within a program. They are also a good way of including very complicated data structures in an ABAP program.

Like all elements in the ABAP type concept, internal tables can exist both as data types and as data objects A data type is the abstract description of an internal table, either in a program or centrally in the ABAP Dictionary, that you use to create a concrete data object. The data type is also an attribute of an existing data object.

Internal Tables as Data Types

Internal tables and structures are the two structured data types in ABAP. The data type of an internal table is fully specified by its line type, key, and table type.

Line type

The line type of an internal table can be any data type. The data type of an internal table is normally a structure. Each component of the structure is a column in the internal table. However, the line type may also be elementary or another internal table.

Key

The key identifies table rows. There are two kinds of key for internal tables - the standard key and a user-defined key. You can specify whether the key should be UNIQUE or NON-UNIQUE. Internal tables with a unique key cannot contain duplicate entries. The uniqueness depends on the table access method.

If a table has a structured line type, its default key consists of all of its non-numerical columns that are not references or themselves internal tables. If a table has an elementary line type, the default key is the entire line. The default key of an internal table whose line type is an internal table, the default key is empty.

The user-defined key can contain any columns of the internal table that are not references or themselves internal tables. Internal tables with a user-defined key are called key tables. When you define the key, the sequence of the key fields is significant. You should remember this, for example, if you intend to sort the table according to the key.

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.

FIELD-SYMBOLS

These r like pointer in C language

data a type i value 10.

field-symbol <f>.

assign a to <f>.

<f> = 20.

write a.

(no u will get the result 20 we r modifing 'a' using the field symbol <f>)

field-symbols are place holders for existing fields. It doesn't physically reserve any space for the fields, but points to the field.

Field symbols are placeholders or symbolic names for other fields. They do not physically reserve space for a field, but point to its contents. A field symbol cam point to any data object. The data object to which a field symbol points is assigned to it after it has been declared in the program.

Simple program.

data : letter(10) .

field-symbols : <fs> type any.

assign letter to <fs> type 'X'.

write <fs>.

Simple program.

TYPES: BEGIN OF NAME,

NEXTNAME(10),

FIRSTNAME(10),

LASTNAME(10),

END OF NAME.

FIELD-SYMBOLS <F> TYPE NAME.

DATA: LINE(30).

LINE = 'JOHN SMITH SHRI'.

ASSIGN LINE TO <F> CASTING.

WRITE: / 'Lastname:', <F>-LASTNAME,

'Firstname:', <F>-FIRSTNAME,

'Nextname :', <F>-NEXTNAME.

Check the below links u will get the answers for your questions

http://help.sap.com/saphelp_nw04/helpdata/en/fc/eb3860358411d1829f0000e829fbfe/content.htm

Hope this resolves your query.

Reward all the helpful answers.

Regards

Former Member · ‎2007 Apr 18