DATA DICTIONARY

Information Stored
Tables : Views
defined independently of the database. A table having the same structure is then created from this table definition in the underlying database logical views on more than one table. A view on the database can then be created from this structure.

Domain and Data Element : A domain defines a value

range. A domain is assigned to a data element. All table fields or structure components that use this data element then have the value range defined by the domain.

Lock objects : Used to synchronize access to the same data

by more than one user.

Search Help : Provision of list of help values for a field .

Structures : Table like object with no data . Key fields can be

set ; search help or check table for a column in a structure can be defined .For currency /quantity fields , reference fields of same/different table can be set.

F1 Help :

Documentation about a field is done in the data element of the field which is availed on pressing F1 key at the field in a program .

Table Type : Describes the structure and functional attributes

of an internal table in ABAP which can be referenced in ABAP program for creating internal table : DATA <inttab> TYPE TTYP.

Tables
Repository of data in the database .

Types :
Transparent Table

Pooled Table

Cluster Table

TRANSPARENT TABLES

1: 1 relationship with a table in the database , with same name , same no. of fields and same of the fields

Table T1

R/3 DDIC Table Definitions

Database Tables

Table T1

Pooled Tables
Table T3 Table T2 Table T4

R/3 DDIC Table Definitions

Database Tables

Many in R/3,one in Database.May/may not have primary key in common

Pooled tables can be used to store control data (e.g. screen sequences,program parameters or temporary data). Several pooled tables can be combined to form a table pool. The table pool corresponds to a physical table on the database in which all the records of the allocated pooled tables are stored.

Following table are pooled tables :T138B T588A T030 Material master screen sequence control Transaction code for HR Infotype Informations Standard Accounts table

Cluster Tables
Table T3 Table T2 Table T4

R/3 DDIC Table Definitions

Database Tables

Many in R/3,one in Database.Must have at least one primary key in common,tables are all read usually at same time

Cluster tables contain continuous text, for example documentation. Several cluster tables can be combined to form a table cluster. Several logical lines of different tables are combined to form a physical record in this table category. This permits object-by-object storage or object-by-object access. In order to combine tables in clusters, at least part of the keys must agree. Several cluster tables are stored in one corresponding table on the database. BSEG , BSED , BSES etc are examples of cluster tables

Restrictions on Pooled and Cluster Tables

Secondary indexes cannot be created . Distinct or Group By Statements cannot be used . Native SQL cannot be used .

Order by statements cannot be used , only order by primary key cannot be used .

Domain,Data Element and Table Field

Data Element

Table

Domain gives technical characteristics,eg, data type and length .

Domain

Data element contains field labels and online documentation(F1 help). Table field is composed of data element .

Data Element
Unstructured type.

Contains type definition (built-in data type, length, number of decimal places), and semantic information. F1 help Documentations are maintained on data element level .
Different field levels are also defined for data elements . Search helps are attached to data element level . Can be elementary type or reference type .Can inherit the data type , length , decimal places etc from a domain or they can be directly assigned .

Data Element (contd..)

A reference type defines the type of the reference variables containing pointers to objects or interfaces. A reference type is defined by specifying an existing class or existing interface. One can also define a generic reference to objects or data objects.

Date element defines the type of a table field, structure component or the row type of a table type. A data element can also be referenced in ABAP programs with TYPE. As a result, variables that take on the attributes of a data element can be defined in an ABAP program.

Field Labels
Used to display a screen field. The structure components and table fields from the ABAP Dictionary can be copied to the input template when one define a screen in the Screen Painter (Get from Dict. function). A field can also be assigned a field label that is derived from the data element of the field. The text of the field label can be translated centrally with the translation tools. The text is then displayed in the input template in the users logon language.

Short, Medium and Long Field Labels

These are keywords of different lengths for identifying screen fields. Since the space available for such texts depends on the input template, the text information can be defined in three different lengths.A maximum length must be assigned for each field label. It is the upper limit for the lengths of all translations of the given text. The maximum length of the field label therefore should be somewhat longer than the given text in the original language.

Headers
This text is used as a column header when you output the contents of fields as a list in the Data Browser. It can also be assigned to a field in the Screen Painter. A maximum length must also be assigned for the header. It is the upper limit for the lengths of all translations of the header. Choose the maximum length of the header to be somewhat longer than the given text in the original language. Also note that the header is often displayed above the corresponding column when preparing list output. The length of the header therefore should not exceed the length of the data element.

Documentation and Documentation Status

Documentation for a data element is displayed when you select F1 Help on each screen field that refers to the data element. If there is no documentation for the data element, only the short text of the data element appears for the F1 help. The documentation status specifies whether documentation has already been written for a data element and whether documentation is in fact required. To display it, choose Goto Documentation Status from the data element maintenance screen. Object should be documented: Standard setting. Documentation either already exists or should be written. Object is not used in any screens: The object is not used in any screen. Documentation does not exist and is not required. Object is explained sufficiently by the short text: The short text explains the object adequately. Documentation does not exist and is not required. Documentation postponed: Used if the use of the data element has not yet been fully clarified.

Data Element Supplementary Documentation Different versions of documentation of same data element to be displayed .

Can be entered from the data element maintenance screen or by pressing F1 in a screen field and then pressing F7 key . A Supplementary documentation no is to be given and a new documentation can be created .

Assign a search help: A search help can be assigned to a data

element , which appears on all the screen fields referring to this data element when the input help (F4 help) is called One must specify the name of the search help in the data element maintenance screen and an export parameter of the search help in the Parameter field.

Assign a parameter ID: A field can be filled with default

values from SAP memory using a parameter ID. A screen field is only filled automatically with the value stored under the parameter ID of the data element if this was explicitly permitted in the Screen Painter.

Domains
Data Element

Table

A domain defines a value range. Referencing the same domain ensures that table fields and structure components having the identical value range can be changed consistently.

Domain

Fixed Values
The value range of a domain can be further restricted by defining fixed values. If fixed values are defined for a domain, these are used in the input check in screen templates. If no other means of help is defined for a field ( search help, foreign key), the fixed values are also offered in the input (F4) help.

One can define fixed value intervals either by entering upper and lower limits or by specifying single values. Value ranges and single values can be combined as required. You can enter an explanatory text for every single value or interval; it is displayed in the input help. It is only possible to define fixed values for domains of data types CHAR, NUMC, DEC, INT1, INT2 and INT4. There is only an input check of the template for data types CHAR and NUMC.

Value Table
In some cases you can see when you define a domain that all the table fields or structure compone nts referring to this domain should be checked against a certain table. This information can be stored in the domain by entering a value table. The system proposes the value table as check table when you try to define a foreign key for the field or component. This proposal can be overridden.

Depending on the data type of the field, there is a conversion from display format to SAP internal format for a screen field . This can be overridden by conversion routines .They have a five-place name(format xxxxx) and are stored as a group of two function modules:-

CONVERSION_EXIT_xxxxx_INPUT CONVERSION_EXIT_xxxxx_OUTPUT

The INPUT module converts from display format to internal format, and the OUTPUT module from internal format to display format.If a screen field refers to a domain with a conversion routine, this conversion routine is executed automatically when entries are saved in this screen field or when values are displayed in this screen field. The conversion routine of the domain is also triggered when the field contents are output with the WRITE statement.

Table Definition
A table definition in the ABAP Dictionary contains the following components: Table fields define the field names and data types of the fields contained in the table Foreign keys define the relationships between the table and other tables. Technical settings control how the table should be created in the database. Indexes: To speed up data selection, secondary indexes can be created for the table The customer can modify SAP tables with append structures and customizing includes.

Reference Fields and Reference Tables

A reference table for fields containing quantities (data type QUAN) or currency amounts (data type CURR) is to be specified. This reference table must contain a field with the format for the currency key (data type CUKY) or unit of measure (data type UNIT). This field is called the reference field of the output field. The reference field can also reside in the table itself.

Includes

In addition to listing the individual fields, you can also include the fields of another structure in tables and structures. Individual fields and includes can be mixed as required.
Structure Included Table

Database Table

CREATING TABLES

Top down Approach :

Creating table first, then the data element and then the domain and so on .

Bottom Up Approach :
Creating Domain first , then the data element and then the table . See the list of Instructions for creating a Table

Adding Records into a Table

Records can be added to a table by programs or by Data browser functionality . To access the data browser , go to SE11 , select the table and enter into it in Change/Display mode . Choose the menu path : Utilities->Table Contents->Create Entries .

Data Browser
There are four data browsers in SAP R/3:-

SE16 , SE17 , SM30 , SM31

SE16 : Allows to enter data, display data using selection

criteria .

SE17 : Allows to display data of a table , using different sort

criteria and appearance criteria for various columns .

SM30 and SM31 : Used to display and update table data .

SM30 is the latest version , which should be used .

SE17 cannot be used for updating or inserting records , but SE16 can . In SE16 , search criteria for a maximum of 40 fields can be entered , but U can enter for any number of columns in SE17 . In SE16 , output can be sorted by single column at a time , SE17 enables to specify any sort sequence across multiple columns .

TABLE MODIFICATION OPERATIONS

Adding an Append Structure Inserting an Include Inserting a New Field Deleting an Existing Field Moving Fields Copy Fields From Other Table Deleting a Table Changing Data Type of a Field

Append Structure
Instructions Zcol1 Zcol2

Table Definition In ABAP/4 Dictionary

Col1 Col2 Col3

Col1

Col2

Col3

Zcol1

Zcol2

Table at Database Level

Inserting an Include Only flat structures may be included in a table.

Place the cursor under the line in which you want to insert the include and choose Edit -> Include -> Insert. 1. A dialog box appears.Enter the structure name. You can optionally enter a group name or a three-place suffix. With the group name, you can access the fields in the include together in ABAP programs.With the group name, you can access the fields in the include together in ABAP programs. 2. The suffix can be used to avoid name collisions between fields of the include and fields already in the table. The suffix is added to all the fields of the include, whereby the field name is first truncated if necessary. 3. Click at the tick button .

Inserting New Fields

Enter into SE11 by choosing a table in changed mode, place the cursor on the field in front of which the new field should be inserted and choose Insert line by right clicking on the field and choosing from the options . You can append several new fields at the end of the table with New lines. Create the new field as necessary and press the Activate key .

Deleting Fields

Enter into SE11 by choosing a table in changed mode, place the cursor on the field which will be deleted and choose Delete line by right clicking on the field and choosing from the options . Then press the activate key .

Moving Fields

Go to SE11 and enter into changed mode for the table which U want to manipulate . Select the field , right click on it and choose Cut from the options . Then place the cursor above which U want to paste the field . Right click on it and choose Paste from the options .Then activate the table .

Copy Fields From Another Table

Select a field of a table in change mode of the table from SE11 and choose from the menu path : Edit->Transfer Fields . Enter the name of the table in the dialog box(which will come) and Choose the Select flds pushbutton . A list of fields will appear . Choose from the list and press the Copy pushbutton . Then right click on the field and choose Paste from the option . The selected field will be pasted above the field . Then , activate the table .

Deleting Tables

In the initial screen of the ABAP Dictionary, select the Database table radiobutton and enter the name of the table. With the where-used list pushbutton (Ctrl+Shift+F3) , check if the table is still used in programs or other objects of the ABAP Dictionary. 1. Choose Delete pushbutton from Application Toolbar . 2. A dialog box appears in which you are asked to confirm the deletion request. This dialog box tells you if the table still contains data. 3. Confirm the deletion request.

Changing Data Types and Lengths of Existing Fields

Procedure for Fields with Data Elements

1. Double-click on the name of the data element.

The data element maintenance screen appears. 2. Double-click on the name of the domain.

The domain maintenance screen appears.

3. Choose Domain Display Change.

Make the required changes and save your entries.

4.Choose Activate key .

Procedure for Fields with Direct Type Entry

1. Place the cursor on the field and choose Data element / Direct type.Values can now be entered in fields Data type, Length, DecPlaces and Short text. 2. Change the entries for the data type, length and possibly the number of decimal places. Save your entries. 3. Choose Activate key.

Foreign Key

Foreign key(fk) in a Table is connected to primary key(pk) table(called check table) by foreign key relationship .

Domain of pk field in check table must be same with that of fk field and the fields should be compatible in data type and length .
Foreign key provides automatic F4 help . Only primary keys of check tables can be referred to by foreign keys . All of the primary keys of check table are to be considered In foreign key relationship.

COMPOUND FOREIGN KEY

Composed of more than one fields , check against the combination of the fields is done against combination of primary keys in the check table .
Among the multiple fields of compound key , there exists a single field , non blank value of which triggers the check . Value in any other fields of compound key does not trigger the validation . This field is Check Field . F4 help is available on the check field of compound foreign key .When F$ help is invoked , pk fields in check table will be displayed and check field will be highlighted .

Cardinality
(X:Y)
Value

Specifies the no. of rows in fk table to be allowed for each row in check table
Y(Refers to dependent
table) For each row in check table,there is always one and only one row in fk table There is atmoset one row in fk tablefor each row in check table Atleast one row in fk table for each row in check table There might or might not be rows in the fk table for each row in check table

X(Refers to check table)

Records in fk table will be deleted if pk values in check table is deleted Deletes are allowed from check table without deleting the corresponding record from foreign key table (Not Applicable) (Not Applicable)

C N CN

Foreign Key Field Type :

Key Fields/Candidates : FK is one of the pk fields / candidate keys of dependent table.
Non key fields/Candidates : Not like above . Key Fields of Text Table : FK is among the pk of a text table (apart from the columns mandt and spras) .
(Table containing spoken language description of values of check table is text table . Description is stored in multiple languages)

Generic Foreign Keys

One have to take all the pk of check table into consideration while establishing the foreign key relationship , but all the columns may not need to be checked . So , to avoid checking against some of the pk fields , it is marked as generic key .

Constant Foreign Key

Compound foreign keys where one of the check table field names is replaced by a constant value .

Adapted Foreign keys

All the foreign key fields of a compound key do not have to reside in the same table , but can be adapted from other table . This adapted key of another table is called adapted foreign key .

Text table
Table 1 is a text table of table 2 if :Key of 1 comprises the key of 2 and an additional language key field (field of data type LANG) Table 2 is the check table for table 1 sharing the common columns. The foreign key field type for the foreign keys in table 1 referring table 2 should be marked as : Key fields of text table . Only one text table can be defined for table 2 .

For demo on Text table , click here

Table Maintenance Generator

Creates standardized maintenance dialogs for tables and views. These dialogs can also be used to maintain table or view contents. Creates maintenance dialogs which are standardized in their: functionality interface maintenance screen navigation enhancement options maintenance

How To Access it
Go to table maintenance screen by transaction SE11 and choose from menu : UtilitiesTable Maintenance Generator

Access transaction : SE55

To maintain table or view contents

Choose at any time from the menupath :Services Ext. tab.maint. Access transaction : SM30

Define maintenance dialog

Following parameters in the maintenance dialog definition screen are to be specified:
Function group: the function group in which the tables/view-specific maintenance dialog components are generated. The function group is created if necessary. Authorization group: the users who are authorized to maintain the table/view contents. Maintenance type: one or two-step dialog. Two step dialog :- Two maintenance screens are processed during the extended table maintenance: On the Overview screen the entries are displayed in list form.

On the Single screen one entry is displayed. The single screen can be called from the overview screen, by function key, for every entry.
One step dialog : Only one maintenance screen is processed during extended table maintenance. The entries are displayed in list form on this screen.

Maintenance screens: the internal number of each maintenance screen. You can get possible values in a search function.
Recording routine: Specify whether and how the table/view contents maintained with the dialog are put in a transport.

Variants of Table Maintenance Generator

After creating table maintenance generator successfully for a table , different variants for a maintained table can be created with different conditions . Or e.g., there is a table YSTUDENT with class , rollno and name .You want to create a variant for the table which will deal with classes 1 to 4 . From the initial screen of table maintenance generator maintenance , choose the menu path : EnvironmentsVariants .

A dialog screen appears . Enter the name of the variant and press Maintenance push button .

Another dialog screen appears . Enter short text and press the Conditions pushbutton .

This screen for entering selection criteria appears . Fill it . Press Further Selection Cond. Pushbutton for further mention of logic .

You can put additional logic lines for same column(Class) or for some other column by pressing the Insert Line pushbutton .

Click at the Checkbox against the column for which U want to incorporate further logic and press Enter .

A line for the chosen column appears . Write the logic here.Press Enter until you come out . A table variant is now ready for maintenance .

Index
Used to access record faster .System searches the records by binary search in presence of index . Basically of Two Types : Primary and secondary . Primary index is created with primary key . Secondary index is created by the user including generally non key fields which build up the selection criteria too often .

 An index is a set of fields from a table that is sorted and then stored in a location separate from itself. Each record in the index contains a pointer to matching records in the actual database table. There are two kinds of indexes, Primary and Secondary (Alternative) Indexes

PRIMARY VS. SECONDARY INDEXES

Primary Index
unique index defined by the primary key every table in the ABAP dictionary automatically has a primary key

Secondary Index
created locally or by SAP defined to support a where clause on a non-primary key field can be unique or non-unique

UNIQUE & NON-UNIQUE INDEXES

Unique Index
only returns one record primary index is always a unique index secondary index may be unique

Non-Unique Index
may return more than one record per query secondary index may be non-unique

FINDING INDEXES
Go to Transaction SE11 and enter table name The primary index fields are marked in the column key To see the secondary index, click on the index pushbutton the following subscreen will appear listing the indexes created for the table.

FINDING INDEXES
In order to display an index, double click on line item.

CREATING INDEXES
From the Previous Subscreen, choose Create Enter Name, and choose Enter

CREATING INDEXES
Enter a short description as well as the Field names

CREATING INDEXES

Choose Index>Activate from the menu path A Message will display Index Table~Index exists in the database system

USING INDEXES
Indexed fields are specified in the Where clause Indexes should be used if All previous fields of a composite (concatenated) index are specified. Data retrieved based on the Where clause is very selective

SELECTIVE DATA
Data is very selective if The indexed column has many distinct values OR Few rows of the indexed column have the same value The percentage of distinct values to total number of rows is high

 An index will not be used if the following operators are present on the indexed fields in your where clause
NOT or NE or <> LIKE %pattern IS NULL IS NOT NULL NOT IN

CASES WHERE INDEXES WONT BE USED

CHOOSING AN INDEX
Must be a sequential list of fields, beginning with the ones specified first in the index. As soon as the index reaches a field that is not used in the query, the remaining fields cant be used.

CHOOSING AN INDEX
For Example: The primary key of table LFB1 consists of client, vendor number, and company code. For a query that selects from this table based on client and company code, the only field that will be used in the index is the client.

EXAMPLE 1: FULL INDEX

Query using full index, all the fields are included:
SELECT fieldn INTO v_fieldn FROM LFB1 WHERE client = value1 AND vendor = value2 AND company code = value3

EXAMPLE 2: PARTIAL INDEX

Query is not using a full index, database can only use client, will skip over company code
SELECT fieldn INTO v_fieldn

FROM LFB1 WHERE client AND company code

= value1 = value3

EXAMPLE 3: OPTIMIZER
Query Forces the Optimizer to use the index
SELECT fieldn INTO
v_fieldn FROM LFB1 WHERE client AND Vendor > AND company code

= value1 = = value3

INDEX RANGE VS. INDEX UNIQUE

Index Unique Scan Retrieves a single row from an index Highly Efficient

Index Range Scan Retrieves one or more matching row from an index Efficiency depends on the number of rows that needs to be retrieved

OPTIMIZING THE USE OF THE OR OPERATOR

Example uses index unique scan using each of the field2 values and concatenating the results - more efficient A database table dbtable1 has an index on field1, field2.
SELECT fieldn INTO v_fieldn FROM dbtable1 WHERE ( field1 = value1 AND field2 = value2 ) OR

( field1 = value1 AND field2 = value3 ) ENDSELECT

OPTIMIZING THE USE OF THE OR OPERATOR

Example uses index range scan - less efficient A database table dbtable1 has an index on field1, field2.
SELECT fieldn INTO v_fieldn FROM dbtable1 WHERE field1 = value AND ( field2 = value2 OR field2 = value3 ) ENDSELECT .

Click here for instructions on creating an index

Structure
Used to define any user-defined types in the ABAP Dictionary. Components of a structure can themselves be structured, that is they can obtain their type from a structure or a table type.

Comprises of components (fields). Types can be defined for the components or can refer to an elementary type (via a data element or by directly specifying the data type and length in the structure definition), another structure or a table type. A structure can therefore be nested to any depth.
Used to define the data at the interface of module pools and screens and to define the parameter types of function modules.

Creating Structures

Table Types

User-defined data types can be stored for all programs in the ABAP Dictionary. These user-defined types provide the same functionality as the local types that can be defined in ABAP programs with TYPES The types defined globally in the ABAP Dictionary can be accessed in ABAP programs with TYPE. You can also refer to the types defined in the ABAP Dictionary when defining the type of a function module interface.

A table type describes the structure and functional attributes of an internal table in ABAP. In ABAP programs you can reference a table type TTYP defined in the ABAP Dictionary with the command DATA <inttab> TYPE TTYP. An internal table <inttab> is created in the program with the attributes defined for TTYP in the ABAP Dictionary.

A table type is defined by: its line type, that defines the structure and data type attributes of a line of the internal table the options for managing and accessing the data ( access mode) in the internal table the key ( key definition and key category) of the internal table The row type is defined by directly entering the data type, length and number of decimal places or by referencing a data element, structured type ( structure, table or view) or other table type.

Key Definition of a Table Type

The key to be used for the table type must be specified.
Standard key: The structure of the key depends on the row type category: In a structured row type, the standard key consists of all the character-like components of the table row. In an elementary row type or reference type as row type, the standard key consists of the entire table row. If the row type is a table type, the standard key is empty. Note that an empty key is only allowed for access mode Standard table. Row type: The key consists of all the fields of the row type. Key components: The key is explicitly defined by selecting components (fields) of the row type. This is only possible if a structure, table or view was selected as row type. Key not specified: The key is not specified. This defines a generic table type.

Access Mode
The access mode defines how to access the data in the internal table defined by the table type when performing key operations (READ TABLE, INSERT TABLE, MODIFY TABLE, COLLECT). In particular, it defines whether key accesses to the internal table are allowed.

Possible access modes are: Standard table:

The key access to a standard table uses a sequential search. The time required for an access is linearly dependent on the number of entries in the internal table.

A standard table is usually accessed with index operations. Sorted table:

The table is always stored internally sorted by its key. Key access to a sorted table can therefore use a binary search. If the key is not unique, the entry with the lowest index is accessed. The time required for an access is logarithmically dependent on the number of entries in the internal table.

Index accesses to sorted tables are also allowed. You should usually access a sorted table using its key.

Hash table:
The table is internally managed with a hash procedure. All the entries must have a unique key. The time required for a key access is constant, that is it does not depend on the number of entries in the internal table. You cannot access a hash table with an index. Accesses must use generic key operations (SORT, LOOP, etc.).

Index table: The table can be a standard table or a sorted table.

Index access is allowed to such an index table. Index tables can be used to define the type of generic parameters of a FORM (subroutine) or a function module.

not specified:
The table can be a standard table, a sorted table or a hash table. The set of valid operations on such a table is the intersection of the valid operations for these three access modes.
You cannot access tables of this type with index operations.

Key Category
The key category defines whether the internal table defined by the table type may only contain keys with a unique key or whether the key may have duplicates.

The following key categories may be defined: unique: This table type may only contain records with a unique key.

non-unique: A table with this table type may also contain records that do not have different keys for the table type.
not specified: The key category is unique or non-unique. This defines a generic table type.

Only certain combinations of access mode and key category are allowed. These are listed in the following table.

Access Mode Not specified Index table Standard table Sorted table Hash table

Key category Not specified Not specified Non-unique Unique, non-unique or not specified Unique

There is one exception: If the key of a standard table or hash table is not specified, you have to select key category not specified.

Generic Table Types

A generic table type does not define all the attributes of an internal table in the ABAP Dictionary; it leaves some of these attributes undefined. A table type is generic in the following cases:

Index table or not specified is selected for the access type,

Not specified is selected for the key definition, Not specified is selected for the key category. Generic table types are used to define the types of generic table parameters in function modules and forms. If a generic table type with the index table access type is used as the parameter of a function module, you can pass either a sorted table or a standard table in the call.

Generic table types offer a degree of freedom in the arguments passed in the corresponding calls.
Since generic table types do not define all the necessary attributes of an internal table, they cannot be used to define data objects (with DATA) or types (with TYPE).

Click below to see the instructions on creating table types

Buffering Database Tables

Improves the performance when accessing the data records contained in the table. Reside locally on each application server . Data can be directly accessed from the buffer instead of database tables , thus saving more time .

Take it from buffer if available

?
Query Take from database,load buffer and access from buffer

Buffer

Database Table

Synchronization Of Buffers

A buffered table is generally read on all application servers and held in the buffer there. If a program changes the data contained in the table on an application server, this is noted in the log table by the database interface. The buffers still have the old status on all the other application servers, so that the programs might read obsolete data.

A synchronization mechanism runs at a fixed time interval, usually every 1-2 minutes. The log table is read and the buffer contents that were changed by other servers are invalidated. In the next access, the data of invalidated tables is read directly from the database and updated in the buffer.

Initial Situation

Database table xmseg is loaded in the buffer of both the application server : server1 and server2 .

Phase I

Server1 deletes records from table xmseg and updates the database.Next, it writes and entry in synchronization table and then updates its local buffer

Phase II

Server2 fetches records of xmseg from its local buffer and selects a record which no longer exists!!!

Phase III

Both servers check the synchronization table to trace any change Server2 finds that table xmseg was modified by server1 .So, it invalidates the data in its local buffer and uses the database the next time it fetches data from xmseg .At this time , the table is again loaded into the local buffer of server2 .
Server1 continues to use its local buffer .

Phase IV

Result :

Both the servers become consistent now .

Types of Buffering
Full Buffering

Generic Buffering

Single Record Buffering

Full Buffering
Buffer
Zero record Match will Also load!!!

All rows loaded from database Irrespective of the criteria.

Appropriate for master tables that seldom change . Loaded by selectendselect block , not by single select statement .

Database

Generic Buffering
Buffer

Group of records ,which match the sort criteria for the pre mentioned number of primary key columns(starting from left) are loaded into buffer . Suitable for tables in which records are usually accessed in sets Database

Single Record Buffering

Buffer

Zero record Match will Also load!!!

Single record loaded from database

Appropriate for master tables that seldom change . Loaded by single select statement , not by select---endselect block

Database

If single record buffer is full , oldest ones(sitting for the long time without being accessed for a long time) are thrown away to make room for the new ones .

The full buffers or generic buffers are periodically unloaded from the buffer within a length of time , determined by caching algorithm within R/3 (depends on the amount of space used by a table in the buffer versus the number of read accesson it in the prv period , volume of free space available in the buffer and the current access quality of the buffer)

 Rarely written (read mostly) tables or for which temporary inconsistencies are of no significance should be buffered. Frequently modified should not be buffered. Otherwise there would be constant invalidation and reloading, which would have a negative effect on the performance.

If a table is buffered , use : bypassing buffer statement to obtain the most recent data before allowing it to be updated .

VIEW

Database View
Application or Purpose dependent vision into the database where records appear from one or more than one tables . Defined in the ABAP Dictionary. A database view is automatically created in the underlying database when it is activated.

Data can be accessed in ABAP program by Native SQL or Open SQL . Involves only transparent tables .Inner Joins are only allowed . Data can be inserted into underlying table if it is a mono table view . Else , for poly table view , data can only be read .

Projection Views
Used to hide fields of a table.

Minimize interfaces by utilizing fields actually needed when a database is accessed .

Contains exactly one table. Selection conditions for projection views cannot be defined. No corresponding object exixts 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. pooled tables and cluster tables can also be accessed with a projection view.

Help Views
Created with outer join for search help . The selection method of a search help is either a table or a view. For records from multiple tables joined by inner join , database view is utilized in search help; if an outer join is needed , help view is used .

All the tables included in a help view must be linked with foreign keys.

Maintenance Views
Data distributed on several tables often forms a logical unit, for example an application object . Maintenance view , depending on the maintenance status , allows to display, modify and create the data of such an application object together. . 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 .Join conditions cannot be directly entered as for database views.

For maintenance views:

Existing view entries can be changed. Records cannot be deleted or inserted. Only entries whose non-time-dependent part of the key is the same as that of existing entries may be inserted Example: A view contains the service code, a date field and a field for the price. The field for the service code is the nontime-dependent component of the key and the field for the date is the time-dependent component of the key.If maintenance status read and change (time-dependent views) was selected for the view, only records that have the same service code as existing records can be inserted with the view. You can also enter a new price for an existing service as of a new date. However, you cannot insert records if they do not yet have a service code.

Restrictions for Maintenance and Help Views

There are some restrictions for selecting the secondary tables of a maintenance view or help view. The secondary tables have to be in an N:1 dependency to the primary table or directly preceding secondary table. This ensures that there is at most one dependent record in each of the secondary tables for a data record in the primary table.

Click here to get instructions on creating views

Search Help(F4 Help)

Produces a list of values for input in a field when F4 is pressed in a field .

Types:
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 helps combine several elementary search helps. A collective search help thus can offer several alternative search paths.

Search help appears as pure display field

Default value added to search help field

If ticked,U can enter search criteria , say CO* and then press F4 which will be copied to input dialog box

If ticked, value from the result list gets returned to the field in the screen

Position in dialog box

Entered when the parameter is to be shown in result for selection

Lock Objects
Used to synchronize access to the same data by more than one program.

When accessing data records, the records just being edited by other programs can be identified by the entry in the lock table. Such an entry for the lock must define a number of fully specified key fields, that is either a value is passed for the key field or this field is locked generically.

To set locks, a lock object must be defined in the ABAP Dictionary and on its activation , two function modules are generated with the names ENQUEUE_<lockobjectname> and DEQUEUE_<lockobjectname>. To lock data records, ENQUEUE_<lockobjectname> is called . The values of the key fields that specify the records to be locked are passed for all the tables contained in the lock object when the function module is called. There is a generic lock if a value is not passed for all the key fields. The function module writes the appropriate lock entry . If another program also requests a lock, it will be accepted or rejected depending on the lock mode . The program can then react to this situation. Locked data records can be unlocked by calling function module DEQUEUE_<lockobjectname>.

This lock procedure requires that all programs involved cooperate. Inconsistencies can occur if a program reads or changes data without having previously locked it. When a lock is set, the data records are only protected against changes by another program if this program also requests a lock before accessing the data.
Instead of writing lock requests or lock releases directly in the lock table, it is also possible to collect them first in a local lock container. The collected locks can be sent at a later time as a group. A parameter of the relevant function module controls whether a lock request or lock release is sent directly.

Structure of a Lock Object

The tables in which data records should be locked with a lock request are defined in a lock object together with their key fields. When tables are selected, one table (the primary table) is first selected. Further tables (secondary tables) can also be added using foreign key relationships

Lock Arguments
The lock argument of a table in the lock object consists of the key fields of the table. They are used as input parameters in the function modules for setting and removing locks generated from the lock object definition. When these function modules are called, the table rows to be locked or unlocked are specified by defining certain values in these fields. These values can also be generic. The lock argument fields therefore define which subset of the table rows should be locked.

A lock mode can be assigned for each table in the lock object. This mode defines how other users can access a locked record of the table.

Lock Mode
Controls whether several users can access data records at the same time. The lock mode can be assigned separately for each table in the lock object. When the lock is set, the corresponding lock entry is stored in the lock table of the system for each table. Exclusive lock: The locked data can only be displayed or edited by a single user. A request for another exclusive lock or for a shared lock is rejected. Shared lock: More than one user can access the locked data at the same time in display mode. A request for another shared lock is accepted, even if it comes from another user. An exclusive lock is rejected. Exclusive but not cumulative: Exclusive locks can be requested several times from the same transaction and are processed successively. In contrast, exclusive but not cumulative locks can be called only once from the same transaction. All other lock requests are rejected.

Function Modules for Lock Requests

Activating a lock object in the ABAP Dictionary automatically creates function modules for setting (ENQUEUE_<lock object name>) and releasing (DEQUEUE_<lock object name>) locks. The generated function modules are automatically assigned to function groups. These function modules and their assignment to function groups should not be changed since the function modules are generated again each time the lock object is activated. Never transport the function groups, which contain the automatically generated function modules. The generated function modules of a lock object could reside in a different function group in the target system. Always transport the lock objects. When a lock object is activated in the target system, the function modules are generated again and correctly assigned to function groups.

Parameters of the ENQUEUE function modules

MODE_<TABLENAME> : Determines lock mode for
each base table . Valid values for this parameter are S (shared), E (exclusive) and X (exclusive but not cumulative).

X_<field> and <field> : X_<field> defines the lock

behavior when the initial value is passed exists for every lock field <field>. If the initial value is assigned to <field> and X_<field>, then a generic lock is initialized with respect to <field>. If <field> is assigned the initial value and X_<field> is defined as X, the lock is set with exactly the initial value of <field>.

_SCOPE : Controls how the lock or lock release is passed to

the update program . _SCOPE = 1: Locks and lock releases are not passed to the update program. The lock is removed when the transaction is ended. _SCOPE = 2: The lock or lock release is passed to the update program. The update program is responsible for removing the lock. The interactive program with which the lock was requested no longer has an influence on the lock behavior. This is the standard setting for the ENQUEUE function module.

_SCOPE = 3: The lock or lock release is also passed to the update program. The lock must be removed in both the interactive program and in the update program.

_WAIT: Decides the lock behavior when there is a lock

conflict. Initial value: If a lock attempt fails because there is a competing lock, the exception FOREIGN_LOCK is triggered. X : If a lock attempt fails because there is a competing lock, the lock attempt is repeated after waiting for a certain time. The exception FOREIGN_LOCK is triggered only if a certain time limit has elapsed since the first lock attempt. The waiting time and the time limit are defined by profile parameters.

_COLLECT : Controls whether the lock request or lock

release should be performed directly or whether it should first be written to the local lock container. This parameter can have the following values: Initial value: The lock request or lock release is sent directly to the lock server. X : The lock request or lock release is placed in the local lock container. The lock requests and lock releases collected in this lock container can then be sent to the lock server at a later time as a group by calling the function module FLUSH_ENQUEUE.

Exceptions of the ENQUEUE Function Module

FOREIGN_LOCK: A competing lock already exists. You can find out the name of the user holding the lock by looking at system variable SY-MSGV1. SYSTEM_FAILURE: This exception is triggered when the lock server reports that a problem occurred while setting the lock. In this case, the lock could not be set. If the exceptions are not processed by the calling program itself, appropriate messages are issued for all exceptions.

Parameters of the DEQUEUE function modules

MODE_<TABLENAME> : Same as enqueue . X_<field> and <field> : Same as enqueue.

_COLLECT : Same as enqueue.

_SCOPE : Same as enqueue.

_SYNCHRON: If X is passed, the DEQUEUE

function waits until the entry has been removed from the lock table. Otherwise it is deleted asynchronously, that is, if the lock table of the system is read directly after the lock is removed, the entry in the lock table may still exist.

Reference Fields for RFC-Enabled Lock Objects

The type of an RFC-enabled function module must be completely defined. The parameters of the generated function module therefore have the following reference fields for RFC-enabled lock objects:
Parameters X_<field name> _WAIT _SCOPE _SYNCHRON Reference fields DDENQ_LIKE-XPARFLAG DDENQ_LIKE-WAITFLAG DDENQ_LIKE-SCOPE DDENQ_LIKE-SYNCHRON

Conditions Required of Foreign Keys

All the tables that can be included in a lock object must be linked with foreign keys. There are a number of restrictions to the valid relationships. 1. The foreign key relationships of the tables of the lock object must form a tree. The tables are the nodes of the tree. The links of the tree mean is the check table of. 2. The foreign key fields must be key fields of the foreign key table. 3. The foreign key relationships defined between the base tables of the lock objects may not have any field that is checked against more than one other field. A field therefore may not occur twice as foreign key field in a relationship and may not be checked against two different fields in two different foreign key relationships.

You must keep one restriction in mind for multi-structured foreign keys. If a field is assigned to a field that is outside the check table, the table containing this field must be in a sub-tree that contains the check table of this foreign key relationship as a root. These conditions are always satisfied if the key of the foreign key table is an extension of the key of the check table.

Conditions 2, 3 and 4 are meaningless if the particular foreign key field was excluded from the assignment to the key fields of the check table by marking it as generic or setting it to a constant. This is also true for multistructured foreign keys if the foreign key field refers to a table that is not contained in the lock object.

Local Lock Containers

Lock requests and lock releases can be collected in a local lock container and sent together by calling the function module FLUSH_ENQUEUE. Advantages : Communications with the lock server are minimized if the lock requests are sent as a group. The collected lock requests are handled as a group, which means that they are only written to the lock table if this is possible for all the individual requests. The local lock container is emptied if all the collected lock requests can be executed; otherwise its contents remain unchanged.

The local lock container can be emptied by calling the function module RESET_ENQUEUE. All the collected lock requests or lock releases are deleted. The local lock container is automatically emptied when the corresponding internal session is ended.
Lock requests and lock releases are managed together in the local lock container. When the collected requests are sent, the lock requests are sent first. The lock releases are sent once all the requested locks have been assigned. The lock requests and lock releases are not adjusted in the local lock container. The order in which the individual requests are written in the local lock container is of no importance.

Click here for demo example on lock objects