ABAP DICTIONARY

LOCK OBJECTS IN SAP ABAP DICTIONARY

2008-06-25T06:28:00.000-07:00

OVERVIEW

Lock objects are use in SAP to avoid the inconsistancy at the time of data is being insert/change into database.

SAP Provide three type of Lock objects.

Read Lock(Shared Locked)

protects read access to an object. The read lock allows other transactions read access but not write access to the locked area of the table

Write Lock(exclusive lock)

protects write access to an object. The write lock allows other transactions neither read nor write access to the locked area of the table.

Enhanced write lock (exclusive lock without cumulating)

works like a write lock except that the enhanced write lock also protects from further accesses from the same transaction.

You can create a lock on a object of SAP thorugh transaction SE11 and enter any meaningful name start with EZ Example EZTEST_LOCK.

Use:

you can see in almost all transaction when you are open an object in Change mode SAP could not allow to any other user to open the same object in change mode.

Example:

in HR when we are enter a personal number in master data maintainance screen SAP can't allow to any other user to use same personal number for changes.

Technicaly:

When you create a lock object System automatically creat two function module.

1. ENQUEUE_. to insert the object in a queue.
2. DEQUEUE_. To remove the object is being queued through above FM.

You have to use these function module in your program.

For sample program check in transaction /ABAPDOCU.

RELATED POST

AGGREGATE FUNCTIONS USAGE IN ABAP PROGRAMMS

n thirteen posts series as given below.

LESSON 1 DATA PORTS IN IDOC

LESSON 2 DEFINING PARTNER PROFILE FOR IDOC

LESSON 3 PARTNE RPROFILES AND PORTS IN IDOC

LESSON 4 CONVERTING DATA INTO IDOC SEGMENTS

LESSON 5 DEVELOPING OUTBOUND IDOC FUNCTION

LESSON 6 CREATION OF IDOC DATA

LESSON 7 IDOC DESIGN AND PROCESSING

LESSON 8 DISPATCHING IDOC

Aggregate Functions usage in ABAP Program

2008-06-18T05:08:00.000-07:00

n You can use aggregate functions (COUNT, SUM, MAX, MIN, AVG) to perform calculations using the DBMS. Only use aggregate functions if they significantly reduce the quantity of data records to be transferred.

n Aggregate functions are usually used used with a GROUP BY clause. SQL statements that contain aggregate functions bypass R/3 table buffers. (Note that this can be a disadvantage if tables are buffered.)

n Field values are processed differently, depending on whether they are in ABAP or at database level. The database uses a different method than ABAP for rounding data (for example, when converting F to I). The database recognizes the value NULL. ABAP does not recognize the value NULL.

For the aggregate function AVG, use data type F (number with floating point) for the target field. For the aggregate function SUM, make the data type of the target field longer than the data type of the source field, to allow for overflow.

Using Having Clause in a sql query:

n To apply a logical condition to the groups defined in the GROUP BY clause, use HAVING with a SELECT statement. The database determines the resulting quantity, that is, the data quantity to be transferred depends on the selectivity of the HAVING clause.

n Using HAVING clauses is similar to using aggregate functions. HAVING clauses create an extra load on the database. Therefore, only use HAVING clauses if they significantly reduce the quantity of data records to be transferred. Before you use a HAVING clause, check whether the condition can be specified in the SELECT clause instead.

Using Array Fetch:

n For SELECT .. ENDSELECT and ARRAY FETCH, the same number of data records must be transferred from the database server to the application server. Since data records are transferred in 32 KB blocks, the transfer load (that is, the number of fetches) is the same for both variants.

n However, an ARRAY FETCH is preferable to a SELECT ... ENDSELECT loop, because data records are transferred per record from the database interface to the ABAP program in a SELECT .. ENDSELECT. Whereas, in an ARRAY FETCH, the data records are transferred to the ABAP program in a block.

Using up to n rows in sql query:

n There are two ways to read a fixed number of data records. You can transfer the data records to the application server using SELECT … ENDSELECT and then determine if the required number of rows has been read. However, using SELECT … UP TO n ROWS is preferable, because only the requested number of data records are transferred from the database to the application.

n In the second version, the UP TO n ROWS addition ensures that only the required data quantity is read from the database and transferred to the database interface.

Accessing individual tables in abap dictionary

2008-06-12T05:47:00.000-07:00

SELECT FOR ALL ENTRIES:

With SELECT FOR ALL ENTRIES, you can divide SELECT statements into loops. This variant enables you to create a JOIN between an internal table and a database table. In the example above, only the records from table KKNA1 are read that have customer numbers in the internal table g_itab_vvbak.

The following problems occur with SELECT FOR ALL ENTRIES:

You cannot have an empty driver table. If the driver table is empty, selection is not limited. Note that if the WHERE clause contains conditions that do not refer to the internal driver table, these conditions are not evaluated either.

Duplicate table entries must be deleted from the internal driver table before the SELECT FOR ALL ENTRIES is executed. If they are not deleted, identical data is read unnecessarily from the database.

If SELECT FOR ALL ENTRIES is used, SQL statements are divided into several SELECT statements by the database interface. The individual SELECT statements are processed on the database and the results are buffered in the database interface. The database interface eliminates duplicate data records from the resulting set, and transfers the overall results to ABAP.

Each SELECT statement processed on the database is executed as a concatenation of individual accesses (for example, index range scans or index unique scans). Concatenation is performed over the entries in the internal driver table. Since SELECT FOR ALL ENTRIES can become very complex, you should avoid combining them with SELECT-OPTIONS or RANGES tables.

Exactly how the WHERE clauses of individual SELECT statements are executed by the database depends on the type of database. The link is generated, for example, using an OR operation as IN list.

USING RANGE:

You can use RANGES tables in ABAP. You can define RANGES tables with the ABAP statements SELECT-OPTIONS and RANGES. These two statements implicitly define an internal table with the fields SIGN, OPTION , LOW and HIGH (see R/3 documentation). The end user at the selection screen dynamically fills a RANGES table defined with SELECT OPTION. The program determines how the RANGES table is filled.

The database interface converts the rows in a RANGES table so that they can be read by the DBMS, and links them with OR. The SQL statement produced is then transferred to the database.

The RANGES table can contain rows with complex expressions (for example, BT => BETWEEN, CP => LIKE). The SQL statement that results from a RANGES table can therefore be complex and difficult for the DBMS to process.

If the program determines how RANGES tables are filled, you must limit the number of entries. If the RANGES table is too large, a complex database statement is generated when the OR or IN list is evaluated. This statement may take a long time to be evaluated on the database. The maximum possible length of the database statement depends on the database (for example, with ORACLE 32 bit version, the maximum is 32 KB). If the maximum length is exceeded, an ABAP dump may be generated

USING AGGREGATE FUNCTIONS:

You can use aggregate functions (COUNT, SUM, MAX, MIN, AVG) to perform calculations using the DBMS. Only use aggregate functions if they significantly reduce the quantity of data records to be transferred.

Aggregate functions are usually used used with a GROUP BY clause. SQL statements that contain aggregate functions bypass R/3 table buffers. (Note that this can be a disadvantage if tables are buffered.)

Field values are processed differently, depending on whether they are in ABAP or at database level. The database uses a different method than ABAP for rounding data (for example, when converting F to I). The database recognizes the value NULL. ABAP does not recognize the value NULL.

65
RELATED POST

USING DATA HINTS IN ABAP SQL QUARY

The links day wise are

SAP SCRIPTS PART 1

SAP SCRIPTS PART 2

SAP SCRIPTS PART 3

SAP SCRIPTS PART 4

SAP SCRIPTS PART 5

Using data base hints in abap reports

2008-06-12T05:34:00.000-07:00

If you want to force the database optimizer to choose a particular execution path, use database hints. In R/3 Releases before 4.5A, database hints can only be used in the respective database-specific SQL dialects (native SQL in the parentheses EXEC SQL. … ENDEXEC.).

As of R/3 Release 4.5A, you can use database hints directly from OPEN SQL. To do this, add the addition %_HINTS DBMS ‘DBHINT’ to the end of the SQL statement. Under DBMS, enter the applicable database system (for example, ORACLE, INFORMIX). Under DBHINT, enter the relevant database-specific hint.

If the hint cannot be interpreted by the database system, it is treated as a comment and does not affect the execution of database statements.

A database hint should be incorporated into an SQL statement only as a last option (regardless of whether it is formulated in native SQL or OPEN SQL). Database hints are database-specific. If you replace the DBMS, you must change all the SQL statements that have database hints (and document your changes).

Database hints ignore the database optimizer's strategy of dynamically making selections according to table and index growth and the selectivity of fields. Therefore, an index that is good today could be bad tomorrow.

Reducing the records to be transfered from SAP Dictionary

To reduce the number of data records to be transferred, for each SQL statement you must specify a WHERE clause that is as selective as possible. A SELECT statement without a WHERE condition is an indication of a design error in the program. You must ensure that the number of selected records remains constant with time, especially when selecting on transaction tables (for example, BKPF, BSEG, COBK, COEP, LIPK, MKPF, VBAK, VBAP).

To reduce the amount of data to be transferred, do not formulate conditions for selecting data using a CHECK statement within a SELECT … ENDSELECT. Instead, formulate conditions as part of a WHERE clause.

Always specify all known conditions in the WHERE clause. Without one, the DBMS cannot use an index to optimize a statement.

To make reusing SQL statements possible, and thus to optimally utilize the DB SQL cache, always adhere to the order of fields specified in the ABAP Dictionary when formulating SELECT clauses and WHERE clauses.

Reducing the columns to be transfered in a program

If you use SELECT *, it is often the case that more data than necessary is transferred from the database server to the application server. If you require the contents of only a few columns, always list the table fields individually in a field list. If the number of fields can be reduced by more than half, creating a field list makes sense.

In this context, the variant SELECT .. INTO TABLE itab PACKAGE SIZE n ENDSELECT is important. PACKAGE SIZE n means that the data is transferred to the internal table itab in packages of n records.

If you need different projections on a database table at different places in a program, read all the required fields at once from the database, buffer them in an internal table, and then distribute the data within the program.

sap index design in data base

SAP SCRIPTS PART 6

SAP SCRIPTS PART 7

SAP SCRIPTS PART 8

SAP SCRIPTS PART 9

SAP SCRIPTS PART 10

SAP SCRIPTS PART 11

SAP SCRIPTS PART 12

SAP SCRIPTS PART 13

Index design in data base for SAP

2008-06-11T04:38:00.000-07:00

Changing the index design of a table in the R/3 System can affect SQL statements other than the one you want to optimize. You must therefore ensure that other SQL statements are not negatively influenced by a new, changed or deleted index.

To do this, you must first establish which database views are referenced on the table. You can find this information in the where-used list in the ABAP Dictionary.

Next, perform an object-related shared SQL area analysis. This means that you restrict the analysis to the relevant tables or database views, rather than finding inefficient SQL statements in the whole system.

After that, change the index design (also activate the indexes, and update the table and index statistics). Immediately after you have changed the index design, reset the DB SQL cache (use the Reset pushbutton).

Repeat the object-related DB SQL cache analysis approximately two days after changing the index design. Because you reset the DB SQL cache, only information is displayed for SQL statements executed after the index design was changed.

To establish in which database views the tables to be analyzed are used, go to the initial screen of the ABAP Dictionary. To do this, from the SAP standard menu choose Tools >> ABAP Workbench >> Dictionary, or use Transaction SE12. Enter the table name in the appropriate field, and choose Where-used list.

In the dialog box that appears, select the checkbox Views and confirm your selection. A list appears, showing all the database views that use the table. You must perform the object-related DB SQL cache analysis for the database views and for the table itself.

To perform an object-related DB SQL cache analysis, first go to the initial screen of the database monitor. To do this, from the SAP standard menu choose Tools >> Administration >> Monitor >> Performance >> Database >> Activity, or use Transaction ST04.

Choose Detail analysis menu >> SQL request. A dialog box appears, where you can limit the SQL statements displayed. Delete the entries in the fields Buffer Gets and Disk Reads. In the Table field, replace the * with the name of the table to be analyzed.

Download to a local file the list of SQL statements contained in the DB SQL cache for the table. Save the Explain SQL display for each SQL statement. Perform the analysis in the same way for all database views that use the table.

A few days after you changed the index design, perform the same analysis again, and for each SQL statement compare the values for logical and physical accesses per execution. This second analysis enables you to ensure that none of the SQL statements analyzed is negatively influenced by the change in index design. The change should affect only the SQL statement to be optimized.

Changing Index design rules part two

2008-06-10T08:40:00.000-07:00

Selective Analysis and distinct values :

When you are sure about what the index fields mean (that is, their semantic meaning), check how many distinct values there are for each index field. Distinct values are the number different values per field in a particular database table.

The relationship between the total number of data records in a table and the distinct values per field indicates how selective the index field is.

When the table and index statistics are updated, the distinct values are re-calculated. For index fields, the number of distinct values can be determined using Explain SQL (DB SQL cache or SQL trace).

For an overview of the distinct values for all fields of a database table, from the SAP standard menu choose Tools >> Administration >> Monitor >> Performance >> Database >> Activity >> Detail analysis menu >> State on disk, or use Transaction DB02. Then choose Detailed analysis. In the dialog box that appears, enter the table name under Object name, and confirm. In the next screen, choose Table columns.

Histograms:

The number of data records returned for each combination of index fields shows how selective an index is. This means that, if only a few data records are returned for a large number of index field combinations, an index is selective.

For an overview of how selective an index is for all index field combinations, a histogram can be calculated. Calculating a histogram is very expensive, because the number of data records returned must be checked for all index field combinations over the whole table.

To perform a selectivity analysis, use Transaction DB05. In the initial screen of DB05, enter a table name, select an analysis for primary key or for specified fields, specify the index fields if applicable, and submit the analysis in background or dialog mode.

If quotients are calculated from the total number of table records (635,336) and the number of distinct values for the index fields (16,607), the results show that an average of 30 data records are returned when the index is used.

If the number of distinct values does not increase from one index field to the next index field, this index field is not selective. It should therefore be omitted.

Remember that a selectivity analysis is an expensive operation, which should only be performed at times of low system activity.

CHANGING THE INDEX DESIGN IN ABAP DICTIONARY PART ONE

Here is the list of all related sap smart forms content placed for reference sake.

SAP SMART FORMS A BRIEF DISCUSSION

SMART FORMS INTRODUCTION AND COMPARISON WITH SCRIPTS

CREATION OF SMART FORMS

CREATION OF SMART FORMS PART TWO

CREATION OF SMART FORMS PART THREE

Changing Index design rules

2008-06-09T04:47:00.000-07:00

An index only makes sense if SQL statements that use the index return less than 5% of the table records. The index fields must therefore significantly reduce the resulting sets. Otherwise, the database optimizer would perform a full table scan anyway.

Indexes must not be contained in other indexes (that is, they must be disjunct), because the cost-based database optimizer can also select the index with the upper quantity. In addition, do not create indexes that can be selected accidentally.

To keep additional work for the database to a minimum, create as few indexes as possible for each table (approximately 5 indexes per table).

As a general rule, an index should consist of a maximum of 4 fields. If too many fields are specified in an index, additional work is created every time a database operation is performed, and the memory space required grows accordingly. Consequently, the index becomes less effective and the probabilty of it being selected is reduced.

The selective fields in an index should be as near to the beginning of the index as possible (see index range scan access strategy). Selective fields are, for example, document number, material number, and customer number. Unselective fields are client, company code, header account, and plant.

Do not change SAP standard indexes unless SAP explicitly recommends that you do so.

Before you perform a technical selectivity analysis, you must be sure what the various index fields in question mean. You should therefore type index fields according to their meaning.

Identifiers: These are particularly selective table fields. They are usually characterized by consecutive numbers (document number, object number, and so on) since they are assigned using a number range object.

Organizational units: These are fields such as sales organization, company code, or distribution channel. They are often very unselective, and should only be used in secondary indexes in exceptional circumstances.

Status fields: These can be very selective if, in an SQL statement, values are selected where only a few corresponding data records exist in the table (for example, open orders, if most of them are complete). Conversely, they can also be very unselective.

Classifiers: These are fields where typing is performed (for example, sales order, planned order, and production order). In general, classifiers are not selective, as few different versions exist, and they are usually distributed relatively evenly.

Date and time: These are often selective, and can be used in a secondary index.

Text fields: These are generally selective, but they are also very long. They should therefore not be used in a secondary index, because it would become too wide.

Problems with data base access in sap abap

2008-06-07T22:57:00.000-07:00

MISSING CRITICAL OPERATORS IN WHERE CLAUSE

If fields in the WHERE clause are specified with operators NOT or <>, these WHERE conditions cannot be used for a search over a database index. You should therefore formulate SQL statements positively wherever possible.

If a positive formulation cannot be used, for example because the IN list would be too long, you should still specify the WHERE condition with NOT, in order to reduce the amount of data to be transferred. An index search will not be performed, but the amount of data returned will be smaller.

On ORACLE databases, a WHERE condition with BETWEEN is evaluated together with the costs for reading 5 % of all index blocks and table blocks, regardless of the size of the BETWEEN interval. If the BETWEEN interval is small enough, you can replace SELECT field list WHERE field BETWEEN value1 AND value5 by SELECT field list WHERE field IN (value1, value2, value3, value4, value5) or by SELECT field list WHERE field IN ranges table.

On ORACLE databases, a WHERE condition with LIKE, > or < field =" ‘999’.">

A field specified with LIKE can narrow the selection of database indexes and be used for a search over a database index only if it does not begin with the wildcard character ‘_’ or ‘%’. In ABAP, the wildcard ‘+’ is used for any character, and ‘*’ is used for any character string. For database accesses, however, the characters ‘_’ and ‘%’ are used.

WHERE conditions with critical operators that are linked to the WHERE clause with OR can be particularly problematic. Since BETWEEN is calculated as costing 5% and LIKE is calculated as costing 10%, the cost-based database optimizer opts for a full table scan after a certain number of corresponding WHERE conditions, instead of using an index.

SORTING

If you want the result of an SQL statement to be returned in a sorted order, use an ORDER BY clause on the database, or use the ABAP statement SORT itab in the program.

Since the database is a central resource and is therefore not scalable, sort in ABAP wherever this is possible. However, if the same database index can be used for sorting and selecting data records (according to the WHERE clause), you can also sort on the database.

CHANGING THE INDEX DESIGN

If you establish that an expensive SQL statement is triggered by an SAP program, first search for R/3 Notes in SAPNet (in a full text search, specify the name of the table or view, as well as the word 'performance'). If you cannot find an applicable R/3 Note, open a problem message in SAPNet.

In your own programs, if you find expensive SQL statements on SAP standard tables with transaction data, avoid creating secondary indexes wherever possible. Transaction data tables usually grow linearly with their indexes. Therefore, a search using a secondary index becomes less effective as time goes on. You should look for alternative methods of access, for example, using index tables or matchcode tables.

Before you create a secondary index to optimize an SQL statement, check whether you can adapt the SQL statement to use a secondary index that already exists. Before you change an index, you must perform a selectivity and interference analysis.

In some cases, deleting a secondary index makes sense. For example, if a secondary index is not used, or if a secondary index is a subset of another index, updating it causes unnecessary work for the database. Before you delete an index, you must perform an interference analysis.

As a rule, avoid secondary indexes over SAP basis tables (for example, tables NAST, D010, D020, or tables beginning with DD).

ABAP DATA BASE ACCESS PROBLEMS PART TWO
Outbound process overview
Outbound process via message control
EDI outbound process
EDI inbound process overview
Inbound process via function module
Inbound process via work flow
EDI subsystem part one and two

Problems with data base access part two

2008-06-07T22:49:00.000-07:00

OLD TABLE INDEX STATISTICS

To ensure that the cost-based database optimizer functions properly, the table and index statistics must be updated regularly. The database optimizer uses these statistics as a basis for selecting the access strategy used to execute a particular SQL statement.

The database administrator must update the table and index statistics regularly. To find out when the last update was performed, from the SAP standard menu choose Tools >> CCMS >> DB administration >> DBA Planning Calendar, or use Transaction DB13. You must ensure that the last update was not performed more than a week ago, and that it was performed successfully (refer to the log).

For making changes to index design, we recommend that roles and responsibilities are distributed as follows. The ABAP programmer designs the database indexes to support SQL statements. In a production system or test system, only the database administrator should be responsible for creating database indexes. The database administrator must verify whether the programmer's index design is correct.

When database indexes are created, the table and index statistics must be updated for the relevant tables. If the index design is correct, you can transport the database index to the production system at a time of low system activity, and then update the table and index statistics in the production system.

MISSING WHERE CONDITIONS

The way in which the database optimizer selects and uses database indexes depends on, among other things, the WHERE conditions specified in the SQL statement. The order of the WHERE conditions in the SQL statement is not important (note that this is not the case with the order of the fields in the database index).

The index search string is concatenated over the fields that are specified without gaps and with '=' in the WHERE condition. The index blocks to be checked are are selected using the index search string.

Using the addition CLIENT SPECIFIED incorrectly can lead to ineffective use of a database index. If you use CLIENT SPECIFIED, specify a WHERE condition for MANDT.

33
RELATED POST

PROBLEMS WITH DATA BASE ACCESS PART ONE
EDI Subsystem architecture and mapping
EDI basic components configuration part one and two
How to set RFC destination part two and part one
Defining a port for message control
EDI Outbound process
Inbound process
Partner profiles configuration part one and two
Overview of outbound parameters part one and two
EDI outbound parameters for message control

Problems with data base access

2008-06-07T22:43:00.000-07:00

Optimizing SQL statements only makes sense if the R/3 System and database system are correctly configured. This is the responsibility of the R/3 System administrator and the database administrator respectively. Technical problems may have an effect on the whole system (for example, wrongly set parameters, communication problems, old table and index statistics), or may only affect SQL statements on certain tables (for example, missing or fragmented indexes).

To avoid technical problems:

ŸFollow the R/3 installation instructions and refer to R/3 Notes

ŸImplement the recommendations given by the SAP standard services GoingLive and EarlyWatch

Communication problems may occur between the application server and database server. Parameters on the database interface may be wrongly set, and thus also cause problems (for example, incorrect value for rsdb/max_blocking_factor, see recommendations for SELECT FOR ALL ENTRIES).

On some databases (for example, Oracle and Informix), fragmented indexes may occur. The term fragmented indexes means that index blocks are less than 50% full. Fragmented indexes can occur if a large number of table records are deleted and then a large number of table records are inserted. If you discover that an index is suitable for an SQL statement, but that executing the SQL statement causes heavy database system load, your database administrator should check whether a fragmented index (database-specific) is causing the problem.

The R/3 Workload monitor gives you an overview of the general state of your R/3 System. To view the initial screen of the R/3 Workload monitor, from the SAP standard menu choose Tools >> CCMS >> Control/Monitoring >> Performance menu >> Workload >> Analysis, or use Transaction ST03.

From this screen, choose Performance database. In the dialog box that appears, first select the server to be checked, then the time period (for example, previous weeks) and the examination period (for example, previous week).

If the average database response time per transaction step is greater than 600ms, the cause is very probably a fundamental R/3 or database problem. If this is the case, the results of the SQL performance trace are not reliable. Your R/3 System administrator or database administrator should therefore first solve the problem, and then you can repeat the analysis.

Missing indexes

Database reorganization or deliberately deleting database objects at the operating system level can cause inconsistencies between the indexes in the ABAP Dictionary and the indexes on the database.

You can find these inconsistencies by using the database monitor. To view the initial screen of the database monitor, from the SAP standard menu choose Tools >> Administration >> Monitor >> Performance >> Database >> Activity >> Detail analysis menu >> State on disk, or use Transaction DB02. For an overview of indexes that are missing in the database or not found in the ABAP Dictionary, choose Missing indexes.

If you find indexes that are missing on the database, inform your database administrator. Database indexes can be activated from this screen or from the ABAP Dictionary, and thus created on the database. Database indexes that exist on the database but not in the ABAP Dictionary can be created in the ABAP Dictionary. They are transferred to the database when they are activated. The index that already exists on the database is then overwritten. After you have changed the index design for a table, you must create new index statistics for the changed indexes.

Only make changes to database indexes at times of low system activity, because the database locks the database table while the indexes are being created.

RELATED POST

DATA BASE JOINS PART TWO
EDI inbound parameter views
Partner profile maintenance
Message control Configuration
Message control architecture part one and two
EDI output types part one and two
Message control and control table
Working of message control part one and two
Message control set up
Work flow management
Using work flow

Data Base Joins part two

2008-06-07T22:37:00.000-07:00

Sort merge join

When a join is processed using the sort merge join access strategy, the following steps are performed:

The table records that correspond to the WHERE clause are selected

The tables in the join are sorted according to the JOIN condition

The table records are merged

For the SQL statement above, the selective WHERE condition for field CUOBJ, table VVBAP, and the selective WHERE condition for field OBJNR, table VVBAK are evaluated. The resulting sets are sorted according to VBELN. The results are then merged.

n If selective WHERE conditions exist for the relevant tables, a sort merge join is very effective. If the JOIN conditions are not selective for any of the relevant tables, the sort merge join access strategy is more effective than a nested loop. If there are more than two tables in the join, you can combine the nested loop and sort merge join access strategies.

Access staginess for data base joins

Nested loop: This strategy is relevant for database views and ABAP JOINs. First, the WHERE clause is used as a basis for selecting the (outer) table to be used for access. Next, starting from the outer table, the table records for the inner tables are selected according to the JOIN condition.

Sort merge join: First, the WHERE clause is evaluated for all tables in the join, and a resulting set is produced for each table. Each resulting set is sorted according to the JOIN conditions and then merged, also according to the JOIN conditions.

RELATED POST

DATA BASE JOINS PART ONE
Architecture of work flow
Business objects
EDI Tasks and roles
Work item and SAP IN box
Error notification process part one and two
Work item in EDI Work flow
EDI Work flow part one, two, three and four
EDI Interface testing
Out bound testing for EDI and part two
Inbound Process utilities

Data Base Joins

2008-06-07T22:25:00.000-07:00

In the R/3 System, users often need to access information stored in different tables. The database-logical operator used to do this is called the JOIN operator.

In ABAP, there are various ways to implement the JOIN operator (nested SELECTs, SELECT FOR ALL ENTRIES, DB views, ABAP JOINS, subqueries, explicit cursor).

If you want the database system to determine the resulting set of the JOIN operator, you can use DB views, ABAP JOINs or subqueries. DB views are first created in the ABAP Dictionary, and are created on the database when the Dictionary object is activated. DB views created by other developers can also be used (reusability). ABAP JOINs are formulated in ABAP directly.

The following important access strategies are available to the database optimizer for processing ABAP JOINs, subqueries, or SQL statements against database views:

Nested Loop:

When a join is processed using the nested loop strategy, two steps are performed:

The order of access is determined

Ÿ Data is selected from the tables

The database optimizer first determines the order in which the tables in the join are to be accessed. To do this, it uses the WHERE clause to estimate the number of returned table records or data blocks for each table in the join.

To determine which table will be the outer table, the optimizer determines the table with the lowest number of returned table records or data blocks, because it assumes that in total the fewest data blocks need to be read in this table.

Therefore, the goal once more is to minimize the number of data blocks to be read (index blocks or table blocks). If there are more than two tables in the join, the inner table is selected in the same way.

In the second step, the table records from the outer table are first selected. For these table records, the table records from the next innermost table are read according to the join condition, and so on.

For the SQL statement above, the optimizer selects the table VVBAK as the outer table, because a selective WHERE condition exists for the field VVBAK-OBJNR. For each table record that fulfills the WHERE condition, table records from VVBUK are selected according to the join condition.

23
RELATED POST

DATA BASE INDEX IN DETAIL
Inbound process testing for EDI
SAP Inbox work item processing
SAP Inbox process log
Idoc's Information display part two and Three
Work Flow display and WORK LOAD analysis on sap SYSTEM AND part two
SAP System logs and analysis part one and two
EDI trouble shooting and Electronic data interchange trouble shooting part two
SAP EDI process restart with ALE tools
EDI Tools for SAP
EDI performance factors

Data Base Index in detail

2008-06-07T22:19:00.000-07:00

Full Table Scan

If the database optimizer selects the full table scan access strategy, the table is read sequentially. Index blocks do not need to be read.

For a full table scan, the read table blocks are added to the end of an LRU list. Therefore, no data blocks are forced out of the data buffer. As a result, in order to process a full table scan, comparatively little memory space is required within the data buffer.

The full table scan access strategy is very effective if a large part of a table (for example, 5% of all table records) needs to be read. In the above example, the full table scan access strategy is not effective, because only a few table records are required, but many table blocks need to be read.

Concatenation

In the concatenation access strategy, one index is reused. Therefore, various index search strings also exist. An index unique scan or an index range scan can be performed for the various index search strings. Duplicate entries in the resulting set are filtered out when the search results are concatenated.

In the SQL statement above, a WHERE condition with an IN operation is specified over field VBELN. The fields MANDT and VBELN are shown on the left of the primary index. Various index search strings are created, and an index range scan is performed over the primary index for each index search string. Finally, the result is concatenated (combined).

Access Staginess

Index unique scan: The index selected is unique (primary index or unique secondary index) and specified fully. One or no table record is returned. This type of access is very effective, because a maximum of four data blocks need to be read.

Index range scan: The index selected is unique or non-unique. In the case of a unique index, not all index fields are specified in the WHERE clause. A range of the index is read and checked. An index range scan may not be as effective as a full table scan. The table records returned can range from none to all.

Full table scan: The whole table is read sequentially. Each table block is read once. Since no index is used, no index blocks are read. The table records returned can range from none to all.

Concatenation: An index is used more than once. Various areas of the index are read and checked. To ensure that the application reads each table record only once, the search results are concatenated, and duplicate entries are eliminated. The table records returned can range from none to all.

SAP Data Base Index Unique Scan

2008-06-07T10:34:00.001-07:00

If, for all fields in a unique index (primary index or unique secondary index), WHERE conditions are specified with '=' in the WHERE clause, the database optimizer selects the access strategy index unique scan.

For the index unique scan access strategy, the database usually needs to read a maximum of four data blocks (three index blocks and one table block) to access the table record.

In the SELECT statement shown above, the table VVBAK is accessed. The fields MANDT and VBELN form the primary key, and are specified with '=' in the WHERE clause. The database optimizer therefore selects the index unique scan access strategy, and only needs to read four data blocks to find the table record requested.

INDEX RANGE SCAN

To execute the SQL statement, the DBMS first reads a root block (1) and a branch block (2). The branch block contains pointers to two leaf blocks (3 and 4). In order to find the index records that fulfill the criteria in the WHERE clause of the SQL statement, the DBMS searches through these leaf blocks sequentially. The index records found point to the table records within the table blocks (5 and 6).

If index records from different index blocks point to the same table block, this table block must be read more than once. In the example above, an index record from index block 3 and an index record from index block 4 point to table records in table block 5. This table block must therefore be read twice. In total, seven data blocks (four index blocks and three table blocks) are read.

The index search string is determined by the concatenation of the WHERE conditions for the fields contained in the index. To ensure that as few index blocks as possible are checked, the index search string should be specified starting from the left, without placeholders ('_' or %). Because the index is stored and sorted according to the index fields, a connected range of index records can be checked, and fewer index blocks need to be read.

The range that can be used to select the index blocks (that is, the fully specified range starting from the left), therefore only consists of the field MANDT. Since many index records fulfill the condition MANDT = ‘001’, a large number of index blocks are read, and their index records checked. All the index records are then filtered out that fulfill the condition VBELN = ‘0000123’. The relevant index records point to the table records.

If a further WHERE condition had been specified in the SQL statement for a field that was not in the index, this WHERE condition would only have been evaluated after the table records had been read from the table blocks.

Due to old update statistics, database errors, missing indexes, or inappropriate ABAP coding, the database optimizer may select a completely unsuitable index, and then perform an unselective index range scan.

In the example above, WHERE conditions are only specified for MANDT and MATNR. In spite of this, the database optimizer chooses to perform an index range scan over the primary index (MANDT, VBELN, POSNR). Since there is only one unselective WHERE condition (MANDT = '001') to select the index blocks (due to the WHERE clause), a large number of index blocks are read. There is no WHERE condition to filter the index records. The table records corresponding to all suitable index records are therefore read.

More data blocks are read if an unselective index range scan is performed, than if the table is read sequentially. This is because a table block is read more than once if index records in different index blocks point to the same table record. The maximum number of data blocks to be read per SQL statement execution is thus calculated from the product of the total number of table blocks and the number of index records per index block.

All index blocks and table blocks read during an index range scan are stored in the data buffer at the top of an LRU (least recently used) list. This can lead to many other data blocks being forced out of the data buffer. Consequently, more physical read accesses become necessary when other SQL statements are executed.

17
RELATED POST

DATA BASE INDEX OVER VIEW
flow here with this four posts.

sap work flow part 1
sap work flow part 2
sap work flow part 3
sap work flow part 4

Data Base Index over view

2008-06-07T10:31:00.000-07:00

Overview

When you create a database table in the ABAP Dictionary, you must specify the combination of fields that enable an entry within the table to be clearly identified. The key fields must be specified at the top of the table field list, and define them as key fields. A minimum of 1 key field and a maximum of 16 key fields can be defined.

When the table is activated, an index formed from all key fields is created on the database (with Oracle, Informix, DB2), in addition to the table itself. This index is called the primary index. The primary index is unique by definition.

In addition to the primary index, you can define one or more secondary indexes for a table in the ABAP Dictionary, and create them on the database. Secondary indexes can be unique or non-unique.

If you dispatch an SQL statement from an ABAP program to the database, the program searches for the data records requested either in the database table itself (full table scan) or by using an index (index unique scan or index range scan). If all fields requested are found in the index using an index scan, the table records do not need to be accessed.

A data block shows the level of detail in which data is written to the hard disk or read from the hard disk. Data blocks can contain several data records. Conversely, a data record can extend over several data blocks.

Data blocks can be index blocks or table blocks. The database organizes the index blocks in the form of a multi-level B* tree. There is a single index block at root level, which contains pointers to the index blocks at branch level. The branch blocks contain either some of the index fields and pointers to index blocks at leaf level, or all index fields and a pointer to the table records organized in table blocks. The index blocks at leaf level contain all index fields and pointers to the table records from the table blocks.

The pointer that identifies one or more table records has a specific name. It is called, for example, ROWID for Oracle databases. The ROWID consists of the number of the database file, the number of the table block, and the row number within the table block.

The index records are stored in the index tree and sorted according to index field. This enables accelerated access using the index. The table records in the table blocks are not sorted.

An index should not consist of too many fields. Having a few very selective fields increases the chance of reusability, and reduces the chance of the database optimizer selecting an unsuitable access path.

DATA BASE OPTIMIZER PART TWO

posts.

Work flow for MM PART 1

Work flow for MM PART 2

Work flow for MM PART 3

Work flow for MM PART 4

Work flow for MM PART 5

Work flow for MM PART 6

Data Base Optimizer part two

2008-06-07T10:24:00.000-07:00

Continued from the last post data base optimizer part one.

Unsuitable access path :

If the single object analysis establishes that an expensive SQL statement has an unsuitable access path, you can narrow (and thus optimize) the search.

The search range is the number of data records that needs to be checked in a table in order to satisfy an SQL statement. When the SQL statement is processed on the database, the search range is dynamically determined by the WHERE clause, the database index used, and the access strategy selected.

You can narrow the search by:

Solving technical problems

Changing the ABAP coding

Changing the index design

Suitable access path:

If the single object analysis establishes that the SQL statement analyzed has a suitable access path, you can optimize it by:

Reducing the rows to be transferred

Reducing the columns to be transferred

Reducing data transfer

Avoiding unnecessary SQL statements

You can reduce the number of rows to be transferred, for example, by optimizing the WHERE clause or by using aggregate functions.

You can reduce the number of columns to be transferred, for example, by formulating a suitable field list or, in the case of database changes, by using UPDATE .. SET field = value.

You can reduce data transfer between database server and application server by formulating your SQL statements in such a way that data is transferred in as large blocks as possible (a full fetch is 32 KB). You can do this by avoiding nested SELECT statements, for example.

Unnecessary SQL statements are either similar or identical SQL statements. Similar SQL statements can often be grouped together. Identical SQL statements can be avoided by buffering data either in an internal table in the program or on the application server.

Hashed Table usage

2008-06-07T10:18:00.000-07:00

What is use of using HASHED TABLE?

Hashed table is useful when your have to work with very big internal table and to read it with

"READ TABLE WITH KEY ..."

The time access is constant !

Definition of a Hashed Table:

"Defines the table as one that is managed with an internal hash procedure. You can imagine a hashed table as a set, whose elements you can address using their unique key. Unlike standard and sorted tables, you cannot access hash tables using an index. All entries in the table must have a unique key.

Access time using the key is constant, regardless of the number of table entries.

You can only access a hashed table using the generic key operations or other generic operations (SORT, LOOP, and so on). Explicit or implicit index operations (such as LOOP ... FROM to INSERT itab within a LOOP) are not allowed."

As long as your records has unique key(s), using hash table will give you a huge performance gain when dealing with large dataset. assuming in your case, 10000 record , and if the key is unique, use hash table. The main use of hash tables is for looking up fixed information from a key. So if you have a report that has personnel number and you want to display their name, you could use a hash table.

Code:

types: begin of typ_pernr,

pernr like pa0001-pernr,

ename like pa0001-ename,

end of typ_pernr.

data: ls_pernr type typ_pernr,

lt_pernr type hashed table of typ_pernr with unique key pernr.

...

select pernr ename into table lt_pernr from pa0001.

...

loop at itab.

read table lt_pernr with table key pernr = itab-pernr

into ls_pernr.

write: ls_pernr-ename, itab-data.

endloop.

DATA BASE OPTIMZER

SAP WORK flow in sales and distribution 1
SAP WORK flow in sales and distribution 2
SAP WORK flow in sales and distribution 3
SAP WORK flow in sales and distribution 4
SAP WORK flow in sales and distribution 5
SAP WORK flow in sales and distribution 6
SAP WORK flow in sales and distribution 7

Data Base Optimizer

2008-06-06T08:52:00.000-07:00

Cost Based Data Base Optimizer

The database optimizer is the most important part of a relational database system. For each SQL statement, the database optimizer determines the strategy for accessing data records. Access can be with database indexes (index access), or without database indexes (full table scan).

The cost-based database optimizer determines the access strategy on the basis of:

conditions in the WHERE clause of the SQL statement

Database indexes of the relevant table(s)

Selectivity of the table fields contained in the database indexes

size of the relevant table(s)

The table and index statistics supply information about the selectivity of table fields, the selectivity of combinations of table fields, and table size.

Before a database access is performed, the database optimizer cannot calculate the exact cost of a database access. It uses the information described above to estimate the cost of the database access.

The optimization calculation is the amount by which the data blocks to be read (logical read accesses) can be reduced. Data blocks show the level of detail in which data is written to the hard disk or read from the hard disk.

Data Base SQL Catche

To avoid repeating the time-consuming and costly procedure of parsing an SQL statement and determining an access strategy, SQL statements are buffered with the chosen access strategy in the DB SQL cache (shared memory area) of the database server.

For a received SQL statement, the DBMS first checks whether the statement already exists in the DB SQL cache. If it does exist, it can be used immediately. If it does not exist, the SQL statement must be parsed and the access strategy must be determined.

Next, the DBMS attempts to read the data blocks required by the SQL statement from the data buffer (logical read access). If this is possible, physical read accesses are not necessary. If this is not possible, the missing data blocks are read from the database files on the hard disk (physical read accesses).

With an appropriate access path:

Here, the SQL statement reads many data blocks in the database and is expensive because it transfers many data records from the database to the application server. Database performance is satisfactory according to the criterion that less than 5 data blocks are read per data record.

Expensive SQL statements with a suitable access path are listed at the top of the Database SQL Cache if they are executed frequently. A problem with the application logic is usually indicated. This problem can be fixed through changes to the ABAP code or to the business process.

With no appropriate access path:

Here, the SQL statement reads many data blocks in the database but does not transfer many data records from the database to the application server. Database performance is not optimal according to the criterion that more than 5 data blocks are read per data record.

Expensive SQL statements with no appropriate access paths can be optimized either by by creating or improving the design of an index, or modifying the ABAP code to improve a poorly designed WHERE clause.

Creating Collective Search Helps

2008-06-06T06:28:00.000-07:00

Procedure

In the initial screen of the ABAP Dictionary, select object class Search help, enter the name of the search help and choose Create.

A dialog box appears in which you must select the type of search help.

Select Collective search help and choose .

The maintenance screen for collective search helps is displayed.

Enter an explanatory text in the field Short text.

You can for example find the search help at a later time using this short text.

In the Definition tab page enter the parameters of the collective search help.

Select the Imp flag if it is an import parameter. Select the Exp flag if it is an export parameter.

Define the types for the parameters of a collective search help by assigning a data element. Enter the name of the data element that describes the contents of the search help parameter in the Data element field.

You can assign the parameter a default value in the Default value field.

In exceptions it could be necessary to change the standard process defined by the search help. You can implement the deviation from the standard using a search help exit.

In this case enter the name of the search help exit in the corresponding field.

On the Included search helps tab page, define the search helps that you want to include in the collective search help.

You can include elementary search helps and collective search helps.

Use the Hide flag to control whether an included search help should appear in the dialog box for selecting the elementary search help. If the flag is set, the search help is not offered.

It makes sense to hide search help inclusions if one or more search paths in the standard system should not be used in a concrete R/3 System. Similarly, search help inclusions can also be already hidden in the standard system because they only can be used meaningfully in a few R/3 Systems. You have to cancel the flag in this case.

Position the cursor one after the other on each allocated search help and choose Parameter assignment.

In the next screen, enter the parameter names of the elementary search helps to which the corresponding parameters of the collective search help should be assigned in the field Reference parameter.

You can select the parameters contained in the included search help using the input help. Create a proposal for the assignment with Proposal.

Save your entries.

A dialog box appears in which you have to assign a development class to the search help.

Choose .

Result

The collective search help is activated. You can find information about the activation flow in the activation log, which you can display with Utilities ® Activation log. If errors occurred when the collective search help was activated, the activation log is automatically displayed.

Do not forget to link the search help to a screen field. The search help attachment is not part of the search help definition; it is part of the object definition to which the search help is attached.

Other Options

You can test the flow of an input help defined by the collective search help with . A dialog box appears in which you can simulate the behavior of the search help under different conditions. You can obtain information about the options provided in this window with .

SAP TABLES

SAP ABAP INTERVIEW ROUND ONE FAQ'S PART TWO

SAP ABAP INTERVIEW ROUND ONE FAQ'S PART THREE

SAP ABAP INTERVIEW ROUND ONE FAQ'S PART FOUR

SAP ABAP INTERVIEW QUESTIONS ON INTERNAL TABLE

SAP ABAP INTERVIEW QUESTIONS ON REPORT FORMATION AND EVENTS

SAP ABAP INTERVIEW QUESTIONS ON MODULARIZATION

SAP ABAP INTERVIEW QUESTIONS ON BASIS LAYER

SAP TABLES

2007-11-06T07:53:00.000-08:00

MM MODULE

CYCLE:
Purchase Requisition (PR) Request for Quotation (RFQ) (Vendor Evaluation)
Purchase Order (PO) Goods Receipt Note (GRN) Invoice Verification Data to FI

Tables and important Fields.

LFA1 – vendor data (LIFNR)
LFB1 -- Company Code Segment : Vendor Data(LIFNR, BUKRS)
LFC1 -- FI Related Vendor Data (LIFNR, BELNR)
LFM1 – Pur. Orgn. Related Vendor Data (LIFNR, EKORG)

MARA – Material Master (MATNR)
MARC – Material Master with Plant Data (MATNR, WERKS)
MARD – Material Master with Storage Location Data (MATNR, LGORT, WERKS)
MAKT – Material Master Material Descriptions (MATNR, MATKL)
MBEW – Material Valuation Data (MATNR, BWTAR)
MVKE – Material Master : Sales related Data
MDKP, MDTB – MRP related Data( Header, Item)
MCHA, MCHB – Material Batches (Header, Item) (MATNR, WERKS, LGORT, CHARG)

EBAN – Pur. Req. Data( BANFN, BNFPO, BADAT, MATNR)
EINA – Purchase Info. Record(General Data)(INFNR, MATNR, LIFNR)
EINE – Purchase Info. Record (pur. Orgn. Data) (INFNR, EKORG)
ELBK, ELBN, ELBP – Vendor Evaluation Related Data
EKKO – PO Data (Header) (EBELN, BSTYP, BSART)
EKPO – PO Data (Item) (EBELN, EBELP, MATNR)
Pur. Req., RFQ and PO are differentiated by Doc Type (BSTYP) in EKKO table.
For RFQ it is ‘A’ and for PO it is ‘F’
MKPF – GRN Data (Header) (EBELN, BLDAT, BUDAT, XBLNR, BKTXT)
MSEG – GRN Data(Item) MBLNR, BWART, LIFNR, MATNR, EBELN)
Apart from this there are lot of tables which begin with ‘M’ & ‘E’, but we
use the following very often.
EQUK – Quota (Header)(QUNUM, MATNR)
EQUP – Quota (Item) (QUNUM, QUPOS, LIFNR)
EKBE – PO History Data (EBELN, EBELP, BELNR, BLDAT, MATNR, VGABE)
EKBZ – PO History with Delivery Costs(EBELN, BELNR, LIFNR, XBLNR)
EKET – Schedule lines data of a PO(EBELN, EINDT, SLFDT)
EKES – Vendor Confirmations Data (EBELN, EBTYP, EINDT, XBLNR)
T163F – Confirmation Texts (EBTYP, EBTXT)
T156 – Movement Types (BWARE)
T024 – Purchasing Groups
T024E – Purchase Organizations
T163 – Item Category’s in Purchasing Documents(PSTYP)
T149D – Valuation Types
T134 – Material Types
FVLK – Delivery Types
STKO, STPO – BOM(Bill Of Material) related Data (Header & Item)
STPU, STPN, STST, STZU – BOM Related Tables
RKPF, RBKP, RSEG (Header & Item) – MM – FI Related Data
KONO, KONH – Pricing data
T006 – Basic Unit Of Measurements

SALES & DISTRIBUTION MODULE RELATED TABLES :

Cycle:
Enquiry  Quotation  Sales Order  Delivery(Picking, Packing, Post Goods Issue and Shipment)  Billing  Data to FI.

TABLES and Important Fields :
VBAK : Sales Document(Header Data) (VBELN)
VBAP : Sales Document(Item Data) (VBELN, POSNR, MATNR, ARKTX, CHARG)
Enquiry, Quotation, Sales Order are differentiated based on Doc.
Type(VBTYP Field) in VBAK, VBAP Tables for Enquiry VBTYP = A, for Quotation ‘B’ & for Order it is ‘C’.)
LIKP : Delivery Table(Header Data) (VBELN, LFART, KUNNR, WADAT, INCOL)
LIPS : Delivery Table(Item Data)(VBELN, POSNR, WERKS, LGORT, MATNR, VGBEL)
(LIPS – VBGELN = VBAK- VBELN, LIPS-VGPOS = VBAP-POSNR)
VTTK : Shipment Table(Header Data) (TKNUM)
VTTP : Shipment Table (Item Data)(TKNUM, TPNUM, VBELN)
(VTTP – VBELN = LIKP – VBELN)
VBRK : Billing Table(Header Data) (VBELN, FKART, BELNF)
VBRP : Billing Table(Item Data) (VBELN, POSNR, FKIMG, NEWR, VGBEL, VGPOS)
(VERP – AUBEL = VBAK- VBELN, VBRP – VBEL = LIKP – VBELN)
Apart from these tables there are lot of other tables which starts with ‘V’, but we use the
following tables frequently.
VBUK: All Sales Documents status & Admn. Data(Header) (VBELN, VBTYP)
VBTYP = ‘C’ (Sales Order) VBTYP = ‘L’(Delivery) VBTYP = ‘M’(Invoice)
VBUP: Sales Documents status & Admin. Data(Item) (VBELN, POSNR)
VBEP : Sales Document Schedule Lines Data (VBELN, POSNR, EDATU, WMENG)
VBKD: To get sales related Business data like Payment terms etc.(VBELN, ZTERM)
VBFA: Sales Document flow data(VBELV, VBELN, POSNV, VBTYP)
VBPA: Partner functions Data(VBELN, PARVW, KUNNR, LIFNR)
TVLKT: Delivery Type: Texts(LFART, VTEXT)
KNA1, KNB1, KNC1 : Customer Master Data and Other Partner’s Data(KUNNR,
NAME1,LAND1)
KNVK: Customer Master Contact Person(PARNR, KUNNR)
KNVV: Customer Master Sales Data.
LFA1, LFB1, LFC1: Vendor Master Data(To get Transporter data)(LIFNR, NAME1, ORT01)
MARA, MARC, MARD : Material Master Data(Basic, Plant, St. Location Views)
TVKO: Sales Organizations(VKORG)
TVKOV: Distribution Channels(VTWEG)
TVTA: Divisions(SPART)
TVKBZ: Sales Office(VKBUR)
TVBVK: Sales Group(VKGRP)
T077D: Customer Account Group(KTOKD)
T001W: Plants(WERKS)
T001L: Storage Locations(LGORT)
TWLAD: To get address of Storage Location and Plant(LGORT, ADRNR)
TVAU: Sales Document (Order) Types
KONV: Condition Types (pricing) (KNUMV, KSCHL, KWETR)
T685T: Condition Types Texts.
ADRC: To get Addresses of Partners
VBBE, VBBS: Sales Requirements Data
VBKA: Sales Activities Data
VBPV: Sales Document Product Proposal

PP & PM Module

AFKO: PP Order Header Data
AFPO: PP Order Item Data
AFVV: Order Operations Data Qty/Date/Values
AFVC: Operations within an Order
AFRU: Order Completion Confirmation
CSLA: Activity Types Master Data
CSLT: Activity Types Texts
KAKO: Capacity Header Segment
CRHD: Work Center Header Data
AUFK: Order Master Data
AFIH: Maintenance Order Header
AUFM: Goods Movement For Order
EQUI: Equipment Master Data
EQKT: Equipment Texts
ILOA: PM Object Location
T024I: Maintenance Planner Groups
T357: Plant Section
IFLO: Functional Location Text
IHSG: Permits in PM
IHGNS: Permit segment in PM
T357G_T: Permit Text
RESB: Reservation / Dependent requirement
V_EQUI: View for Equipment description
VIAUFKS: View for Order and Equipment Data
CAVFVD: Work Center Text.
VIQMEL: Notification Header View
VIQMFEL: PM Notification View
VIQMMA, VIQMSM : Views for Activities and Tasks

FI/CO Module

T001: Company Codes
T002: Language Keys
T003: FI Document Types
T004: Chart Of Accounts
T005: Country Keys
T007A: Tax Keys
T012: House Banks
TKA01: Controlling Areas
SKA1, SKB1: G/L Account Master data
SKAT : G/L Accounts Texts
KNBK: Customer Master(Bank Details)
LFBK: Vendor Master (Bank Details)
BKPF: Accounting Doc. Header
BSEG: Accounting Doc. Item(Cluster Table)
BSIS: G/L Open Items
BSAS: G/L Closed Items
BSID: Customer Open Items(Account Receivables)
BSAD: Customer Closed Items)(Account Receivables)
BSIK: Vendor Open Items(Account Payables)
BSAK: Vendor Closed Items(Account Payables)
BKPF and BSEG Tables consists of data from BSIS, BSAS, BSID, BSAD, BSIK, and BSAK tables.
BSET: Tax Information
BSEC: One Time Vendor Records
CSKS: Cost Center Master
CSKT: Cost Center Texts
CSSK: Cost Center/ Cost Element Relations
GLPCA: EC-PCA: Actual Line Items
GLPCT: EC-PCA: Totals Table
COEP: Co-Object Line Items by Period
COST: Co-Object Price Totals
CSSL: Cost Center- Activity Type
CRCO: Work Center- Cost Center Assignment
CSLA: Activity Types Master(LSTAR)
CSKB: Cost Elements(KSTAR, KOKRS)
COSS: Cost Totals(OBJNR, KSTAR)
COBL: Coding Block
CEPC: Profit Center Master Data
BNKA: Master Records of banks
TBSL: Posting Keys
KEKO: Product Costing Header Data
ANLH: Main Asset Number
ANLA, ANLB, ANLC : Segment Assets Masters

RELATED POSTS

SEARCH HELP
ABAP VIEWS
DEPENDENCIES OF DICTIONARY OBJECTS
CONSITENCY THROUGH INPUT CHECKS
PERFORMANCE DURING TABLE ACCESS
ABAP DICTIONARY BRIEF
DATA BASE DIALOG IN ABAP
TYPES OF TABLES IN SAP
BUFFERING IN SAP
SYSTEM FIELDS IN SAP
IMPLEMENTING A SAP PROJECT DIFFERENT STAGES
SAP ABAP FAQ'S ON RFC

SAP ABAP OPTIMIZATION

SAP ABAP CROSS APPLICATIONS

ABAP ASSIGNMENT

ABAP REAL TIME INTERVIEW QUESTIONS PART ONE

ABAP REAL TIME INTERVIEW QUESTIONS PART TWO

ABAP REAL TIME INTERVIEW QUESTIONS PART THREE

TABLE TYPES IN ABAP

2007-11-04T04:21:00.000-08:00

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.

RELATED POSTS

SEARCH HELP
ABAP VIEWS
DEPENDENCIES OF DICTIONARY OBJECTS
CONSITENCY THROUGH INPUT CHECKS
PERFORMANCE DURING TABLE ACCESS
abap communication interface 1

abap communication interface 2

abap communication interface 3

abap communication interface 4

abap communication interface 5

abap communication interface 6

SELECTION METHOD ON SEARCH HELP IN ABAP

2007-11-02T02:30:00.000-07:00

The possible values displayed for a field by the input help are determined at runtime by a selection from the database. When a search help is defined, you must define the database object from which the data should be selected by specifying a table or a view as the selection method.

It makes sense to use a view as selection method if the data about the possible values that is relevant for the input help is distributed on several tables. If this data is all in one table or in the corresponding text table, you can use the table as a selection method. The system automatically ensures that the text of the text table is used in the user's logon language.

If there is not yet a view that combines the data that is relevant for an input help, you must first create it in the ABAP Dictionary.

Maintenance views may not be used as the selection method for search helps. Normally a database view is used. However, you should note that database views (in the R/3 System) are always created with an inner join. As a result, only those values having an entry in each of the tables involved are offered in the input help. Sometimes the values should be determined with an outer join.

If the selection method of a search help is client-dependent, the possible values are only selected in the user's logon client.

DESCRIPTION OF DIALOG BEHAVIOR:

The possible values are presented in the dialog box for displaying the hit list and the user can select values from here. If the possible values are formal keys, further information should also be displayed.

If the hit list is very large, the user should be able to define further restrictions for the attributes of the entry. Restricting the set of data in this way both increases the clarity of the list and reduces the system load. Additional conditions can be entered in a further dialog window, the dialog box for restricting values.

The dialog type of a search help defines whether the dialog box for restricting values should be displayed before determining the hit list.

You must define the characteristics to appear on either (or both) of the dialog boxes as parameters in the search help. You can use all the fields of the selection method (with the exception of the client field) and the non-key fields of your text table as parameters.

You define which parameter should appear in which dialog box (in what order) by assigning the parameters positions in the two dialog boxes. You can thus use different parameters (or different orders) in the two dialog boxes.

Types must be defined for search help parameters with data elements. These define the display in the two dialog boxes. If nothing else is defined, a parameter uses the data element of the corresponding field of the selection method.

INTERFACE OF SEARCH HELP:

When you define a parameter of a search help, you must also define whether it should be used to copy data to the input help (IMPORT parameter) or whether to return data from the input help (EXPORT parameter).

The IMPORT and EXPORT parameters of a search help together make up your interface. (This is also analogous to function modules.)

You can also define interface parameters that do not appear in either the dialog box for displaying the hit list or the dialog box for restricting values. This is useful for example when screen fields that do not appear on either of the two dialog boxes are to be updated when you select a value.

The location from which the IMPORT parameters of a search help get their values and the screen fields in which the contents of the EXPORT parameters of the search help are returned are defined in the search help attachment.

The search field is a special case. Its contents are only used in the input help if it is a search string (that is, if it contains a ´*´ or a ´+´) and the parameter linked with the search field is an IMPORT parameter.

Parameters that only contain additional information about the search field should not be defined as IMPORT parameters since the user must otherwise empty the corresponding screen fields each time before he can define a new value with the input help.

HOW TO USE SEARCH HELP?

A search help describes the flow of an input help. The search help can only take effect using a mechanism that assigns the search help to this field. This mechanism is called the search help attachment to the field.

Attaching a search help to a field has an effect on the field's behavior. It is therefore considered to be part of the field definition.

The semantic and technical attributes of a screen field (type, length, F1 help, ...) are not normally defined directly when the input template is defined. On the contrary, only a reference to an ABAP Dictionary field (usually with the same name) is specified in the Screen Painter. The screen field takes on the attributes of this field from the ABAP Dictionary.

The same principle is also used to define the input help of a screen field. The search help is thus attached to the ABAP Dictionary search field and not to the screen field.

In the search help attachment, the interface parameters of the search help and the screen fields providing data for the input help or getting data from the input help are assigned to one another. The search field must be assigned to an EXPORT parameter of the search help at this time. This parameter should also be an IMPORT parameter so that the user can take advantage of search patterns that are already entered.

Fields that do not have a search help attachment can also have an input help since further mechanisms (e.g. domain fixed values) are also used for the F4 help.

SEARCH HELP ATTACHMENT IN ABAP DICTIONARY:

There are three mechanisms for attaching a search help to a field of the ABAP Dictionary.

A search help can be attached directly to a field of a structure or table. The definition of this attachment is analogous to that of a foreign key. You have to define an assignment (between the interface parameters of the search help and the fields of the structure) for which the system makes a proposal.

If a field has a check table, its contents are automatically offered as possible values in the input help. The key fields of the check table are displayed. If a check table has a text table, its first character-like non-key field is displayed.

If you are not satisfied with the described standard display of the data of the check table, you can attach a search help to the check table. This search help is used for all the fields that have this table as check table. You have to define an assignment between the interface of the search help and the key of the check table when you define the attachment.

The semantics of a field and its possible values are defined by its data element. You can therefore attach a search help to a data element. The search help is then available for all the fields that refer to this data element. In the attachment you must define an EXPORT parameter of the search help for the data transfer.

Attaching a search help to a check table (or a data element) can result in a high degree of reusability. However, there are restrictions on passing further values via the interface of the search help.

(135)

RELATED POSTS

series.
SAP SCRIPT CONTROLS PART 1
SAP SCRIPT CONTROLS PART 2
SAP SCRIPT CONTROLS PART 3
SAP SCRIPT CONTROLS PART 4
SAP SCRIPT CONTROLS PART 5
SAP SCRIPT CONTROLS PART 6

TYPES OF TABLES IN SAP
BUFFERING IN SAP
SYSTEM FIELDS IN SAP
IMPLEMENTING A SAP PROJECT DIFFERENT STAGES

SEARCH HELP IN ABAP

2007-11-01T05:27:00.000-07:00

SEARCH HELP IN ABAP :

The input help (F4 help) is a standard function of the R/3 System. It permits the user to display a list of possible values for a screen field. A value can be directly copied to an input field by list selection.

The fields having an input help are shown in the R/3 System by the input help key to the right of the field. This key appears as soon as the cursor is positioned on the corresponding screen field. The help can be started either by clicking on this screen element or with function key F4.

If the number of possible entries for a field is very large, you can limit the set of displayed values by entering further restrictions.

The display of the possible entries is enhanced with further useful information about the displayed values. This feature is especially useful if the field requires the entry of a formal key.

Since the input help is a standard function, it should look and behave the same throughout the entire R/3 System. The development environment therefore provides tools for assigning a standardized input help to a screen field.

The precise description of the input help for a field is usually defined by its semantics. For this reason, the input help for a field is normally defined in the ABAP Dictionary.

WHY DO U NEED SEARCH HELP?

A number of requirements must be met for the input help of a screen field (search field):

Information (about the context) known to the system must be taken into consideration in the input help. This includes entries the user already made in the current input template as well as information obtained in previous dialog steps. Normally the input help uses the context to limit the set of possible values.

The input help must determine the values that can be offered to the user for selection. The data to be displayed as supplementary information in the list of possible values must also be determined. When the possible values are determined, the restrictions resulting from the context and from further search conditions specified by the user must also be taken into consideration.

The input help must hold a dialog with the user. This dialog always contains the presentation of the possible values (with supplementary information) in list form and the possibility to select a value from this list. A search template in which the user can define conditions for the values to be displayed is also sometimes required

If the user selects a value, the input help must return it to the search field. The input template often contains more fields (often only display fields) containing further explanatory information about the search field. The input help should also update the contents of these fields in this case.

The ABAP Dictionary object search help:

The ABAP Dictionary object search help is used to describe an input help. The definition of a search help contains the information the system needs to satisfy the described requirements.

The interface of the search help controls the data transfer from the input template to the F4 help and back. The interface defines the context data to be used and the data to be returned to the input template when a value is selected.

The internal behavior of the search help describes the F4 process itself. This includes the selection method with which the values to be displayed should be determined as well as the dialog behavior describing the interaction with the user.

As with a function module, search helps distinguish between the interface with which it exchanges data with other software components and the internal behavior (for function modules, the latter is defined by the source text).

It only makes sense to define a search help if there is a mechanism available with which the search help can be accessed from a screen. This mechanism is called the search help attachment and will be described later.

Like the editor for function modules, the editor for search helps also enables you to test an object. You can thus test the behavior of a search help without assigning it to a screen field.

SELECTION METHOD OF SEARCH HELP:

The possible values displayed for a field by the input help are determined at runtime by a selection from the database. When a search help is defined, you must define the database object from which the data should be selected by specifying a table or a view as the selection method.

It makes sense to use a view as selection method if the data about the possible values that is relevant for the input help is distributed on several tables. If this data is all in one table or in the corresponding text table, you can use the table as a selection method. The system automatically ensures that the text of the text table is used in the user's logon language.

If there is not yet a view that combines the data that is relevant for an input help, you must first create it in the ABAP Dictionary.

Maintenance views may not be used as the selection method for search helps. Normally a database view is used. However, you should note that database views (in the R/3 System) are always created with an inner join. As a result, only those values having an entry in each of the tables involved are offered in the input help. Sometimes the values should be determined with an outer join. In this case you should choose a help view as the selection method. You can find more information about help views in the appendix.

If the selection method of a search help is client-dependent, the possible values are only selected in the user's logon client.

(131)

RELATED POSTS
Happy coding.

ADD CORRESPONDING

ASSIGN PART ONE

ASSIGN PART TWO

CONTROL BREAK

EVENTS IN LISTS

EVENTS IN LISTS PART TWO

EVENTS ON SELECTION SCREEN PART ONE

EVENTS ON SELECTION SCREEN PART TWO

INNER AND OUTER JOINS IN ABAP

2007-11-01T05:24:00.000-07:00

INNER AND OUTER JOINS IN ABAP:

The set of data that can be selected with a view greatly depends on whether the view implements an inner join or an outer join.

With an inner join, you only get those records which have an entry in all the tables included in the view. With an outer join, on the other hand, those records that do not have a corresponding entry in some of the tables included in the view are also selected.

The hit list found with an inner join can therefore be a subset of the hit list found with an outer join.

Database views implement an inner join. You only get those records which have an entry in all the tables included in the view.

Maintenance views implement an outer join.

(124)

RELATED POSTS

AUTHORITY CHECK

BACK

BREAK POINT

CALL FUNCTION PART ONE

CALL FUNCTION PART TWO

CALL FUNCTION PART THREE

CALL FUNCTION PART FOUR

CALL FUNCTION PART FIVE

ABAP VIEWS

2007-11-01T05:15:00.000-07:00

NEED OF VIEWS:

Data for an application object is often distributed on several database tables. Database systems therefore provide you with a way of defining application-specific views on data in several tables. These are called views.

Data from several tables can be combined in a meaningful way using a view (join). You can also hide information that is of no interest to you (projection) or only display those data records that satisfy certain conditions (selection).

The data of a view can be displayed exactly like the data of a table in the extended table maintenance.

Given two tables TABA and TABB. Table TABA contains 2 entries and table TABB 4 entries.

The tables are first appended to one another. This results in the cross-product of the two tables, in which each record of TABA is combined with each record of TABB.

Usually the entire cross-product is not a meaningful selection. You should therefore limit the cross-product with a join condition. The join condition describes how the records of the two tables are related.

In our example, Field 3 of TABB identifies Field 1 of TABA. The join condition is then:
TABA - Field 1 = TABB - Field 3

With this join condition, all the records whose entry in Field 1 is not identical to the entry in Field 3 are removed from the cross product. The column for Field 3 in the view is therefore unnecessary.

STRUCTURE OF A VIEW:

Often some of the fields of the tables involved in a view are of no interest. You can explicitly define the set of fields to be included in the view (projection).

The set of records that can be displayed with the view can be further restricted with a selection condition.

In our example, only those records with value 'A' in Field 4 should be displayed with the view.

A selection condition therefore can also be formulated with a field that is not contained in the view.

The join conditions can also be derived from the existing foreign key relationships. Copying the join conditions from the existing foreign keys is supported in the maintenance transaction.

The field names of the underlying table fields are normally used as field names in the view. However, you can also choose a different field name. This is necessary for instance if two fields with the same name are to be copied to the view from different tables. In this case you must choose a different name for one of the two fields in the view.

Selection with a database view, however, is usually more efficient than selection with a nested SELECT statement.

As of Release 4.0 you can formulate the join condition directly in OPEN SQL.

A view has type character and can be accessed in programs like all other types and can be used to define data objects.

DATA BASE VIEWS:

A database view is defined in the ABAP Dictionary and automatically created on the database during activation. Accesses to a database view are passed directly to the database from the database interface. The database software performs the data selection.

If the definition of a database view is changed in the ABAP Dictionary, the view created on the database must be adjusted to this change. Since a view does not contain any data, this adjustment is made by deleting the old view definition and creating the view again in the ABAP Dictionary with its new definition.

The maintenance status defines whether you can only read with the view or whether you can also write with it. If a database view was defined with more than one table, this view must be read only.

The data read with a database view can be buffered. View data is buffered analogously to tables. The technical settings of a database view control whether the view data may be buffered and how this should be done. The same settings (buffering types) can be used here as for table buffering. The buffered view data is invalidated when the data in one of the base tables of the view changes.

INCLUDES IN DATA BASE VIEWS:

You can include entire tables in database views. In this case all the fields of the included table become fields of the view (whereby you can explicitly exclude certain fields). If new fields are included in the table or existing fields are deleted, the view is automatically adjusted to this change. A new or deleted field is therefore automatically included in the view or deleted from it.

If an append structure is added to a table included in a view, the fields added with the append structure are automatically included in the view.

To include a table in a view, you must enter the character '*' in field View field in the view maintenance, the name of the table to be included in the field Table and the character '*' again in the field Field name.

If you do not want to insert a field of the included table in the view, you must enter a '-' in field View field, the name of the included table in field Table and the name of the field to be excluded in field Field name.

As of Release 4.6C, fields of the base tables of a database view can be included in the view without modifications using an append view. This is analogous to enhancing a table using an append structure. An append view is assigned to exactly one database view. But more than one append view can be created for a database view.

MAINTENANCE VIEWS:

Data that is distributed on more than one table often forms a logical unit, called an application object. You should be able to display, change and create the data of such an application object together. Users usually are not interested in the technical implementation of the application object, such as the distribution of the data on several tables.

You can maintain complex application objects in a simple way using a maintenance view. The data is automatically distributed on the underlying database tables.

All the tables used in a maintenance view must be linked with a foreign key. This means that the join conditions are always derived from the foreign key in the maintenance view. You cannot enter the join conditions directly as in a database view.

A maintenance interface with which the data of the view can be displayed, changed and created must be generated from the definition of a maintenance view in the ABAP Dictionary.

When the maintenance interface is created, function modules that distribute the data maintained with the view on the underlying tables are automatically generated.

The maintenance interface is generated with the Transaction Generate Table View (Transaction SE54) or from the view maintenance screen with Utilities -> Tab.maint.generator.

(116)

RELATED POSTS

DATA BASE TABLES
CALL METHOD

CALL SCREEN

CALL TRANSACTION

CHECK

CHECK WITH IN LOOP

CLEAR

CLOSE AND CNT

COLLECT

COMMIT

APPEND STRUCTURE

2007-11-01T05:09:00.000-07:00

APPEND STRUCTURE:

Append structures permit you to append customer fields to a SAP standard table without having to modify the table definition.

An append structure is a structure which is assigned to exactly one table. There can be several append structures for a table.

When a table is activated, all the active append structures for the table are found and their fields are appended to the table. If an append structure is created or changed, the table to which it is assigned is also activated and the changes also take effect there when it is activated.

Like all structures, an append structure defines a type that can be used in ABAP programs.

With Release 4.6C you can define foreign keys for fields that already exist in the table using an append structure. Search helps can also be attached to fields that already exist in the table.

Customers create append structures in their namespace. The append structures are thus protected against overwriting during an upgrade.

The new versions of the standard tables are imported during the upgrade. When the standard tables are activated, the fields contained in the active append structures are appended to the new standard tables. When append structures are added to a table, you therefore do not have to manually adjust the customer modifications to the new SAP version of the table (Transaction SPDD) during the upgrade.

The order of the fields in the ABAP Dictionary can differ from the order of the fields in the database. You therefore do not have to convert the table when you add an append structure or insert fields in an existing append structure. The new fields are simply appended to the table in the database. You can always adjust the structure by adjusting the database catalog (ALTER TABLE).

The new version of the SAP standard table is activated and the new field is appended to the database table.

Please note the following points about append structures:

No append structures may be created for pooled and cluster tables.

If a long field (data type LCHR or LRAW) occurs in a table, it cannot be extended with append structures. This is because such long fields must always be in the last position of the field list, i.e. they must be the last field of the table.

If you as a customer add an append structure to an SAP table, the fields in this append structure should be in the customer namespace for fields, that is they should begin with YY or ZZ. This prevents name collisions with new fields inserted in the standard table by SAP.

If you as a partner have your own reserved namespace for your developments, the fields you select in append structures should always lie in this namespace.

(103)

RELATED POSTS

IMPLEMENTING A SAP PROJECT DIFFERENT STAGES

COMMUNICATION PART ONE

COMMUNICATION PART TWO

COMMUNICATION PART THREE

COMMUNICATION PART FOUR

COMMUNICATION PART FIVE

COMPUTE PART ONE

COMPUTE PART TWO

CHANGES TO DATA BASE TABLES

2007-11-01T01:17:00.000-07:00

CHANGES TO DATA BASE TABLES:

Correct access by ABAP programs to a database table is only possible if the runtime object of the table is consistent with the structure of the table in the database. Each time the table is changed in the ABAP Dictionary, you must check if the database structure of the table must be adjusted to the changed ABAP Dictionary definition of the table when it is activated (when the runtime object is rewritten).

The database structure does not have to be altered for certain changes to the ABAP Dictionary. For example, you do not have to change the database structure when the order of the fields in the ABAP Dictionary is changed (other than for key fields). In this case the changed structure is simply activated in the ABAP Dictionary and the database structure remains unchanged.

The database table can be adjusted to the changed definition in the ABAP Dictionary in three different ways:

By deleting the database table and creating it again. The table on the database is deleted, the inactive table is activated in the ABAP Dictionary, and the table is created again on the database. Data existing in the table is lost.

By changing the database catalog (ALTER TABLE). The definition of the table on the database is simply changed. Existing data is retained. However, indexes on the table might have to be built again.

By converting the table. This is the most time-consuming way to adjust a structure.

If the table does not contain any data, it is deleted in the database and created again with its new structure. If data exists in the table, there is an attempt to adjust the structure with ALTER TABLE. If the database system used is not able to do so, the structure is adjusted by converting the table.

EXAMPLE:

CONVERSION PROCESS :

The following example shows the steps necessary during conversion.

Starting situation: Table TAB was changed in the ABAP Dictionary. The length of field 3 was reduced from 60 to 30 places.

The ABAP Dictionary therefore has an active (field 3 has a length of 60 places) and an inactive (field 3 still has 30 places) version of the table.

The active version of the table was created in the database, which means that field 3 currently has 60 places in the database. A secondary index with the ID A11, which was also created in the database, is defined for the table in the ABAP Dictionary.

The table already contains data.

Step 1: The table is locked against further structure changes. If the conversion terminates due to an error, the table remains locked. This lock mechanism prevents further structure changes from being made before the conversion has been completed correctly. Data could be lost in such a case.

Step 2: The table in the database is renamed. All the indexes on the table are deleted. The name of the new (temporary) table is defined by the prefix QCM and the table name. The name of the temporary table for table TAB is therefore QCMTAB.

Step 3: The inactive version of table TAB is activated in the ABAP Dictionary. The table is created in the database with its new structure and with the name QCM8TAB. The primary index on the table is also created in the database. The structure of database table QCM8TAB is the same as the structure of the active table in the ABAP Dictionary after this step. The database table, however, still does not contain any data.

The table therefore does not exist in the database with its original name during conversion. Programs that access this table therefore cannot be executed. You should therefore always make sure that no applications access the table to be converted during conversion.

Step 4: The data is loaded back from table QCMTAB to table QCM8TAB (with MOVE-CORRESPONDING). The data is in both tables after this step. When you reduce the size of fields, for example, the extra places are truncated when you reload the data.

Since the data is in both tables QCM8TAB and QCMTAB during the conversion, there are greater storage requirements during conversion. You should therefore check whether there is sufficient space available in the corresponding tablespace before converting large tables.

There is a database commit after 16 MB when you copy the data from table QCMTAB to table QCM8TAB. A conversion process therefore needs 16 MB resources in the rollback segment. The existing database lock is released with the Commit and then requested again before the next data area to be converted is edited.

When you reduce the size of keys, only one record can be reloaded if there are several records whose key cannot be distinguished. It is not possible to say which record this will be. In such a case you should clean up the data of the table before converting.

Step 5: Table QCM8TAB is renamed to TAB. The secondary indexes defined in the ABAP Dictionary for the table are created again. The views on the table deleted in the first step of the conversion are also created again in the database.

Step 6: Table QCMTAB is deleted.

Step 7: The lock set at the beginning of the conversion is deleted.

If the conversion terminates, the table remains locked and a restart log is written.

Caution: The table does not exist in the database with its original name during conversion. Programs therefore may not access the table during conversion. Conversions therefore should not run during production! You must at least deactivate all the applications that use the tables to be converted.

You must clean up terminated conversions. Programs that access the table will otherwise not run correctly. In this case you must find out why the conversion terminated (for example overflow of the corresponding tablespace) and correct it. Then continue the terminated conversion.

POSSIBLE PROBLEMS DURING CONVERSIONS:

Since the data exists in both the original table and temporary table during conversion, the storage requirements increase during conversion. If the tablespace overflows when you reload the data from the temporary table, the conversion will terminate. In this case you must extend the tablespace and start the conversion in the database utility again.

If you shorten the key of a table (for example when you remove or shorten the field length of key fields), you cannot distinguish between the new keys of existing records of the table. When you reload the data from the temporary table, only one of these records can be loaded back into the table. It is not possible to say which record this will be. If you want to copy certain records, you have to clean up the table before the conversion.

During a conversion, the data is copied back to the database table from the temporary table with the ABAP statement MOVE-CORRESPONDING. Therefore only those type changes that can be executed with MOVE-CORRESPONDING are allowed. All other type changes cause the conversion to be terminated when the data is loaded back into the original table. In this case you have to recreate the old state prior to conversion. Using database tools, you have to delete the table, rename the QCM table to its old name, reconstruct the runtime object (in the database utility), set the table structure in the Dictionary back to its old state and then activate the table.

RESUMING TERMINATED CONVERSIONS:

If a conversion terminates, the lock entry for the table set in the first step is retained. The table can no longer be edited with the maintenance tools of the ABAP Dictionary (Transaction SE11).

A terminated conversion can be analyzed with the database utility (Transaction SE14) and then resumed. The database utility provides an analysis tool with which you can find the cause of the error and the current state of all the tables involved in the conversion.

You can usually find the precise reason for termination in the object log. If the object log does not provide any information about the cause of the error, you have to analyze the syslog or the short dumps.

If there is a terminated conversion, two options are displayed as pushbuttons in the database utility:

After correcting the error, you can resume the conversion where it terminated with the Continue adjustment option.

There is also the Unlock table option. This option only deletes the existing lock entry for the table . You should never choose Unlock table for a terminated conversion if the data only exists in the temporary table, i.e. if the conversion terminated in steps 3 or 4.

(95)

RELATED POSTS

COMPUTE PART THREE

CONCATENATE

CONDENSE

CONSTANTS

TABLE CONTROL

CONVERT

CREATE

DEPENDENCIES OF ABAP DICTIONARY OBJECTS

2007-10-31T19:48:00.000-07:00

ACTIVE AND INACTIVE VERSIONS:

During development, you sometimes need to change an (active) object already used by the system. Such changes are supported in the ABAP Dictionary by separating the active and inactive versions.

The active version of an ABAP Dictionary object is the version that the components of the runtime environment (for example ABAP processor, database interface) access. This version is not initially changed.

An inactive version is created when an active object is changed. The inactive version can be saved without checking. It has no effect on the runtime system.

At the end of the development process, the inactive version can be made the active version. This is done by activation. The inactive version of the object is first checked for consistency. If it is consistent, the inactive version replaces the active one. From now on, the runtime system uses the new active version.

RUN TIME OBJECTS:

The information about a structure (or table) is distributed in the ABAP Dictionary in domains, data elements, and the structure definition. The runtime object (nametab) combines this information into a structure in a form that is optimized for access from ABAP programs. The runtime object is created when the structure is activated.

The runtime objects of the structures are buffered so that the ABAP runtime system can quickly access this information.

The runtime object contains information about the overall structure (e.g. number of fields) and the individual structure fields (field name, position of the field in the structure, data type, length, number of decimal places, reference field, reference table, check table, conversion routine, etc.).

The runtime object of a table contains further information needed by the database interface for accessing the table data (client dependence, buffering, key fields, etc.).

Runtime objects are created for all ABAP Dictionary objects that can be used as types in ABAP programs. These are data elements, table types and views, as well as structures and tables.

HANDLING OF DEPENDING OBJECTS:

If an object that is already active is modified, this can affect other objects that use it (directly or indirectly). These objects using another object are called dependent objects. On the one hand, it might be necessary to adjust the runtime objects of these dependent objects to the changes. On the other hand, a change might sometimes make a dependent object inconsistent.

For this reason, the dependent objects are determined and activated (if necessary) when an active object is activated. The active versions of the dependent objects are activated again. In particular, new and inactive versions of objects using the changed object are not changed.

If an ABAP Dictionary object has a table as dependent object, its database object as well as its runtime object might have to be adjusted when the dependent object is activated.

WHERE USED LISTS:

Changing an ABAP Dictionary object might also affect its dependent objects. Before making a critical change (such as changing the data type or deleting a field) you should therefore define the set of objects affected in order to estimate the implications of the planned action.

There is a where-used list for each ABAP Dictionary object with which you can find all the objects that refer to this object. You can call the where-used list from the maintenance transaction of the object.

You can find direct and indirect usages of an ABAP Dictionary object with the where-used list. You also have to define which usage object types should be included in the search (e.g. all structures and tables using a data element). You can also search for usages that are not ABAP Dictionary objects (e.g. all programs using a table). The search can also be limited by development class or user namespace.

If an object is probably used by several objects, you should perform the search in the background.

REPOSITORY INFORMATION:

The Repository Information System ABAP Dictionary is part of the general Repository Information System. It helps you search for ABAP Dictionary objects and their users.

The where-used list for Repository objects can be called from the information system. The information system also enables you to search for objects by their attributes.

In addition to the object-specific search criteria (e.g. buffering type for tables), you can search for all objects by development class, short description or author and date of last change.

The object lists created by the Repository Information System are entirely integrated in the ABAP Workbench. They permit you to navigate directly to the maintenance transactions of the objects found.

(83)

RELATED POSTS

DATA PART ONE

DATA PART TWO

DATA PART THREE

DATA PART FOUR

DATA PART FIVE

DATA PART SIX

DEFINE

CONSISTENCY

2007-10-30T20:23:00.000-07:00

The domain describes the value range of a field by specifying its data type and field length. If only a limited set of values is allowed, they can be defined as fixed values.

Specifying fixed values causes the value range of the domain to be restricted by these values. Fixed values are immediately used as check values in screen entries. There is also an F4 help.

Fixed values are only checked in screens. No check is made when data records are inserted in a table by an ABAP program.

Fixed values can either be listed individually or defined as an interval.

The value range of a field can also be defined by specifying a value table in the domain.

In contrast to fixed values, however, simply specifying a value table does not cause the input to be checked. There is no F4 help either.

If you enter a value table, the system can make a proposal for the foreign key definition.

A value table only becomes a check table when a foreign key is defined.
If you refer to a domain with a value table in a field, but no foreign key was defined at field level, there is no check.

In the ABAP Dictionary, such relationships between two tables are called foreign keys and they must be defined explicitly for the fields.

Foreign keys are used to ensure that the data is consistent. Data that has been entered is checked against existing data to ensure that it is consistent.

A combination of fields of a table is called a foreign key if this field combination is the primary key of another table.

A foreign key links two tables.

The check table is the table whose key fields are checked. This table is also called the referenced table.

An entry is to be written in the foreign key table. This entry must be consistent with the key fields of the check table.

The field of the foreign key table to be checked is called the check field.

Foreign keys can only be used in screens. Data records can be written to the table without being checked using an ABAP program.

In the ABAP Dictionary, the same domain is required for the check field and referenced key field of the check table so that you do not compare fields with different data types and field lengths. Domain equality is essential. Different data elements can be used, but they must refer to the same domain.

The requirement for domain equality is only valid for the check field. For all other foreign key fields, it is sufficient if the data type and the field length are equal. You nevertheless should strive for domain equality. In this case the foreign key will remain consistent if the field length is changed because the corresponding fields are both changed. If the domains are different, the foreign key will be inconsistent if for example the field length is changed.

If the domain of the check field has a value table, you can have the system make a proposal with the value table as check table. In this case a proposal is created for the field assignment in the foreign key.

The cardinality describes the foreign key relationship with regard to how many records of the check table are assigned to records of the foreign key table. The cardinality is always defined from the point of view of the check table.

The type of the foreign key field defines whether or not the foreign key field identifies a table entry. This means that the foreign key fields are either key fields or they are not key fields or they are a special case, namely the key fields of a text table.

There are the following kinds of foreign key fields:

not specified: No information about the kind of foreign key field can be given

no key fields/candidates: The foreign key fields are neither primary key fields of the foreign key table nor do they uniquely identify a record of the foreign key table (key candidates). The foreign key fields therefore do not (partially) identify the foreign key table.

Key fields/candidates: The foreign key fields are either primary key fields of the foreign key table or they uniquely identify a record of the foreign key table (key candidates). The foreign key fields therefore (partially) identify the foreign key table.

Key fields of a text table: The foreign key table is a text table of the check table, i.e. the key of the foreign key table only differs from the key of the check table in an additional language key field. This is a special case of the category Key fields / candidates

(71)

RELATED POSTS

DELETE PART ONE

DELETE PART TWO

DELETE PART THREE

DELETE PART FOUR

DELETE PART FIVE

DELETE FROM DATA

DELETE PROGRAM

DESCRIBE PART ONE

DESCRIBE PART TWO

INDEXING AND BUFFERING

2007-10-30T10:15:00.000-07:00

PERFORMACE DURING TABLE AINDEXINGCCESS :

An index can be used to speed up the selection of data records from a table.

An index can be considered to be a copy of a database table reduced to certain fields. The data is stored in sorted form in this copy. This sorting permits fast access to the records of the table (for example using a binary search). Not all of the fields of the table are contained in the index. The index also contains a pointer from the index entry to the corresponding table entry to permit all the field contents to be read.

When creating indexes, please note that:

An index can only be used up to the last specified field in the selection! The fields which are specified in the WHERE clause for a large number of selections should be in the first position.

Only those fields whose values significantly restrict the amount of data are meaningful in an index.

When you change a data record of a table, you must adjust the index sorting. Tables whose contents are frequently changed therefore should not have too many indexes.

Make sure that the indexes on a table are as disjunct as possible.

The database optimizer decides which index on the table should be used by the database to access data records.

You must distinguish between the primary index and secondary indexes of a table. The primary index contains the key fields of the table. The primary index is automatically created in the database when the table is activated. If a large table is frequently accessed such that it is not possible to apply primary index sorting, you should create secondary indexes for the table.

The indexes on a table have a three-character index ID. '0' is reserved for the primary index. Customers can create their own indexes on SAP tables; their IDs must begin with Y or Z.

If the index fields have key function, i.e. they already uniquely identify each record of the table, an index can be called a unique index. This ensures that there are no duplicate index fields in the database.

When you define a secondary index in the ABAP Dictionary, you can specify whether it should be created on the database when it is activated. Some indexes only result in a gain in performance for certain database systems. You can therefore specify a list of database systems when you define an index. The index is then only created on the specified database systems when activated.

Table buffering increases the performance when the records of the table are read.

The records of a buffered table are read directly from the local buffer of the application server on which the accessing transaction is running when the table is accessed. This eliminates time-consuming database accesses. The access improves by a factor of 10 to 100. The increase in speed depends on the structure of the table and on the exact system configuration. Buffering therefore can greatly increase the system performance.

If the storage requirements in the buffer increase due to further data, the data that has not been accessed for the longest time is displaced. This displacement takes place asynchronously at certain times which are defined dynamically based on the buffer accesses. Data is only displaced if the free space in the buffer is less than a predefined value or the quality of the access is not satisfactory at this time.

Entering $TAB in the command field resets the table buffers on the corresponding application server. Only use this command if there are inconsistencies in the buffer. In large systems, it can take several hours to fill the buffers. The performance is considerably reduced during this time.

The R/3 System manages and synchronizes the buffers on the individual application servers. If an application program accesses data of a table, the database interfaces determines whether this data lies in the buffer of the application server. If this is the case, the data is read directly from the buffer. If the data is not in the buffer of the application server, it is read from the database and loaded into the buffer. The buffer can therefore satisfy the next access to this data.

The buffering type determines which records of the table are loaded into the buffer of the application server when a record of the table is accessed. There are three different buffering types.

With full buffering, all the table records are loaded into the buffer when one record of the table is accessed.

With generic buffering, all the records whose left-justified part of the key is the same are loaded into the buffer when a table record is accessed.

With single-record buffering, only the record that was accessed is loaded into the buffer.

With full buffering, the table is either completely or not at all in the buffer. When a record of the table is accessed, all the records of the table are loaded into the buffer.

When you decide whether a table should be fully buffered, you must take the table size, the number of read accesses and the number of write accesses into consideration. The smaller the table is, the more frequently it is read and the less frequently it is written, the better it is to fully buffer the table.

Full buffering is also advisable for tables having frequent accesses to records that do not exist. Since all the records of the table reside in the buffer, it is already clear in the buffer whether or not a record exists.

The data records are stored in the buffer sorted by table key. When you access the data with SELECT, only fields up to the last specified key field can be used for the access. The left-justified part of the key should therefore be as large as possible for such accesses. For example, if the first key field is not defined, the entire table is scanned in the buffer. Under these circumstances, a direct access to the database could be more efficient if there is a suitable secondary index there.

With generic buffering, all the records whose generic key fields agree with this record are loaded into the buffer when one record of the table is accessed. The generic key is a left-justified part of the primary key of the table that must be defined when the buffering type is selected. The generic key should be selected so that the generic areas are not too small, which would result in too many generic areas. If there are only a few records for each generic area, full buffering is usually preferable for the table. If you choose too large a generic key, too much data will be invalidated if there are changes to table entries, which would have a negative effect on the performance.

A table should be generically buffered if only certain generic areas of the table are usually needed for processing.

Client-dependent, fully buffered tables are automatically generically buffered. The client field is the generic key. It is assumed that not all of the clients are being processed at the same time on one application server. Language-dependent tables are a further example of generic buffering. The generic key includes all the key fields up to and including the language field.

The generic areas are managed in the buffer as independent objects. The generic areas are managed analogously to fully buffered tables. You should therefore also read the information about full buffering.

Only those records that are actually accessed are loaded into the buffer. Single-record buffering saves storage space in the buffer compared to generic and full buffering. The overhead for buffer administration, however, is higher than for generic or full buffering. Considerably more database accesses are necessary to load the records than for the other buffering types.

Single-record buffering is recommended particularly for large tables in which only a few records are accessed repeatedly with SELECT SINGLE. All the accesses to the table that do not use SELECT SINGLE bypass the buffer and directly access the database.

If you access a record that was not yet buffered using SELECT SINGLE, there is a database access to load the record. If the table does not contain a record with the specified key, this record is recorded in the buffer as non-existent. This prevents a further database access if you make another access with the same key.

You only need one database access to load a table with full buffering, but you need several database accesses with single-record buffering. Full buffering is therefore generally preferable for small tables that are frequently accessed.

Since the buffers reside locally on the application servers, they must be synchronized after data has been modified in a buffered table. Synchronization takes place at fixed time intervals that can be set in the system profile. The corresponding parameter is rdisp/bufreftime and defines the length of the interval in seconds. The value must lie between 60 and 3600. A value between 60 and 240 is recommended.

Advantages and disadvantages of this method of buffer synchronization:

Advantage: The load on the network is kept to a minimum. If the buffers were to be synchronized immediately after each modification, each server would have to inform all other servers about each modification to a buffered table via the network. This would have a negative effect on the performance.

Disadvantage: The local buffers of the application servers can contain obsolete data between the moments of synchronization.

This means that:

Only those tables which are written very infrequently (read mostly) or for which such temporary inconsistencies are of no importance may be buffered.

Tables whose entries change frequently should not be buffered. Otherwise there would be a constant invalidation and reload, which would have a negative effect on the performance.
(48)

RELATED POSTS

DESCRIBE PART THREE

DESCRIBE PART FOUR

DESCRIBE PART FIVE

DESCRIBE PART SIX

DESCRIBE PART SEVEN

DETAIL

DIVIDE

DO

TABLES IN ABAP DICTIONARY

2007-10-27T21:10:00.000-07:00

The structure of the objects of application development are mapped in tables on the underlying relational database.

The attributes of these objects correspond to fields of the table.

A table consists of columns (fields) and rows (entries). It has a name and different attributes, such as delivery class and maintenance authorization.

A field has a unique name and attributes; for example it can be a key field.

A table has one or more key fields, called the primary key.

The values of these key fields uniquely identify a table entry.

The basic objects for defining data in the ABAP Dictionary are tables, data elements and domains. The domain is used for the technical definition of a table field (for example field type and length) and the data element is used for the semantic definition (for example short description).

A domain describes the value range of a field. It is defined by its data type and length. The value range can be limited by specifying fixed values.

A data element describes the meaning of a domain in a certain business context. It contains primarily the field help (F1 documentation) and the field labels in the screen.

A field is not an independent object. It is table-dependent and can only be maintained within a table.

You can enter the data type and number of places directly for a field. No data element is required in this case. Instead the data type and number of places is defined by specifying a direct type.

The data type attributes of a data element can also be defined by specifying a built-in type, where the data type and number of places is entered directly.

A transparent table is automatically created on the database when it is activated in the ABAP Dictionary. At this time the database-independent description of the table in the ABAP Dictionary is translated into the language of the database system used.

The database table has the same name as the table in the ABAP Dictionary. The fields also have the same name in both the database and the ABAP Dictionary. The data types in the ABAP Dictionary are converted to the corresponding data types of the database system.

The order of the fields in the ABAP Dictionary can differ from the order of the fields on the database. This permits you to insert new fields without having to convert the table. When a new field is added, the adjustment is made by changing the database catalog (ALTER TABLE). The new field is added to the database table, whatever the position of the new field in the ABAP Dictionary.

ABAP programs can access a transparent table in two ways. One way is to access the data contained in the table with OPEN SQL (or EXEC SQL). With the other method, the table defines a structured type that is accessed when variables (or more complex types) are defined.

You can also create a structured type in the ABAP Dictionary for which there is no corresponding object in the database. Such types are called structures. Structures can also be used to define the types of variables.

Structures can be included in tables or other structures to avoid redundant structure definitions.

A table may only be included as an entire table.

A chain of includes may only contain one database table. The table in which you are including belongs to the include chain. This means that you may not include a transparent table in a transparent table.

Includes may contain further includes.

Foreign key definitions are generally imparted from the include to the including table. The attributes of the foreign key definition are passed from the include to the including table so that the foreign key depends on the definition in the include.

You must maintain the technical settings when you define a transparent table in the ABAP Dictionary.

The technical settings are used to individually optimize the storage requirements and accessing behavior of database tables.

The technical settings can be used to define how the table should be handled when it is created on the database, whether the table should be buffered and whether changes to entries should be logged.

The table is automatically created on the database when it is activated in the ABAP Dictionary. The storage area to be selected (tablespace) and space allocation settings are determined from the settings for the data class and size category.

The settings for buffering define whether and how the table should be buffered.

You can define whether changes to the table entries should be logged.

The data class logically defines the physical area of the database (for ORACLE the tablespace) in which your table should be stored. If you choose the data class correctly, the table will automatically be created in the appropriate area on the database when it is activated in the ABAP Dictionary.

The most important data classes are master data, transaction data, organizational data and system data.

Master data is data that is rarely modified. An example of master data is the data of an address file, for example the name, address and telephone number.

Transaction data is data that is frequently modified. An example is the material stock of a warehouse, which can change after each purchase order.

Organizational data is data that is defined during customizing when the system is installed and that is rarely modified thereafter. The country keys are an example.

System data is data that the R/3 System itself needs. The program sources are an example.

Further data classes, called customer data classes (USER, USER1), are provided for customers. These should be used for customer developments. Special storage areas must be allocated in the database.

The size category describes the expected storage requirements for the table on the database.

An initial extent is reserved when a table is created on the database. The size of the initial extent is identical for all size categories. If the table needs more space for data at a later time, extents are added. These additional extents have a fixed size that is determined by the size category specified in the ABAP Dictionary.

You can choose a size category from 0 to 4. A fixed extent size, which depends on the database system used, is assigned to each category.

Correctly assigning a size category therefore ensures that you do not create a large number of small extents. It also prevents storage space from being wasted when creating extents that are too large.

Modifications to the entries of a table can be recorded and stored using logging.

To activate logging, the corresponding field must be selected in the technical settings. Logging, however, only will take place if the R/3 System was started with a profile containing parameter 'rec/client'. Only selecting the flag in the ABAP Dictionary is not sufficient to trigger logging.

Parameter 'rec/client' can have the following settings:

rec/client = ALL All clients should be logged.

rec/client = 000[...] Only the specified clients should be logged.

rec/client = OFF Logging is not enabled on this system.

The data modifications are logged independently of the update. The logs can be displayed with the Transaction Table History (SCU3).

Logging creates a 'bottleneck' in the system:

Ÿ Additional write access for each modification to tables being logged.

Ÿ This can result in lock situations although the users are accessing different application tables!

(32)

ABAP DICTIONARY INTRODUCTIOIN

2007-10-26T08:10:00.000-07:00

The ABAP Dictionary permits a central management of all the data definitions used in the R/3 System.

In the ABAP Dictionary you can create user-defined types (data elements, structures and table types) for use in ABAP programs or in interfaces of function modules. Database objects such as tables and database views can also be defined in the ABAP Dictionary and created with this definition in the database.

The ABAP Dictionary also provides a number of services that support program development. For example, setting and releasing locks, defining an input help (F4 help) and attaching a field help (F1 help) to a screen field are supported.

Tables and database views can be defined in the ABAP Dictionary.

These objects are created in the underlying database with this definition. Changes in the definition of a table or database view are also automatically made in the database.

Indexes can be defined in the ABAP Dictionary to speed up access to data in a table. These indexes are also created in the database.

There are three different type categories in the ABAP Dictionary:

Data elements: Describe an elementary type by defining the data type, length and possibly decimal places.

Structures: Consist of components that can have any type.

Table types: Describe the structure of an internal table.

Any complex user-defined type can be built from these basic types.

Example: The data of an employee is stored in a structure EMPLOYEE with the components NAME, ADDRESS and TELEPHONE. Component NAME is also a structure with components FIRST NAME and LAST NAME. Both of these components are elementary, i.e. their type is defined by a data element. The type of component ADDRESS is also defined by a structure whose components are also structures. Component TELEPHONE is defined by a table type (since an employee can have more than one telephone number).

Types are used for example in ABAP programs or to define the types of interface parameters of function modules.

The ABAP Dictionary supports program development with a number of services:

Input helps (F4 helps) for screen fields can be defined with search helps.

Screen fields can easily be assigned a field help (F1 help) by creating documentation for the data element.

An input check that ensures that the values entered are consistent can easily be defined for screen fields using foreign keys.

The ABAP Dictionary provides support when you set and release locks. To do so, you must create lock objects in the ABAP Dictionary. Function modules for setting and releasing locks are automatically generated from these lock objects; these can then be linked into the application program.

The performance when accessing this data can be improved for database objects (tables, views) with buffering settings.
By logging, you can switch on the automatic recording of changes to the table entries.

The ABAP Dictionary is actively integrated in the development and runtime environments. Each change takes immediate effect in the relevant ABAP programs and screens.

Examples:

When a program or screen is generated, the ABAP interpreter and the screen interpreter access the type definitions stored in the ABAP Dictionary.

The ABAP tools and the Screen Painter use the information stored in the ABAP Dictionary to support you during program development. An example of this is the Get from Dictionary function in the Screen Painter, with which you can place fields of a table or structure defined in the ABAP Dictionary in a screen.

The database interface uses the information about tables or database views stored in the ABAP Dictionary to access the data of these objects.

RELATED POSTS

FORM

FORM PART TWO

FORMAT

FORMAT PART TWO

FORMAT PART THREE

FREE

GENERATE

GET PART ONE AND TWO THREE

GET CURSOR PART ONE TWO

GET CURSOR PART ONE AND TWO