Explore topic-wise InterviewSolutions in .

• INTERNAL Subroutines: The source CODE of the internal subroutines will be in the same ABAP/4 program as the CALLING procedure (internal CALL).
• External Subroutines: The source code of the external subroutines will be in an ABAP/4 program other than the calling procedure.

• INPUT PARAMETERS are USED to pass DATA to subroutines.
• Output parameters are used to pass data from subroutines.

Database UTILITY is the interface between the ABAP/4 Dictionary and the UNDERLYING the SAP system. The database utility is the interface between the ABAP/4 Dictionary and the relational database underlying the SAP system. You can call the database utility from the INITIAL screen of the ABAP/4 Dictionary with UTILITIES Database utility. The database utility allows you to create, delete and convert OBJECTS from the ABAP/4 Dictionary in the database.

Database utility is the interface between the ABAP/4 Dictionary and the underlying the SAP system. The database utility is the interface between the ABAP/4 Dictionary and the relational database underlying the SAP system. You can call the database utility from the initial screen of the ABAP/4 Dictionary with Utilities Database utility. The database utility allows you to create, delete and convert objects from the ABAP/4 Dictionary in the database.

When two users simultaneously attempt to access the same data RECORD, this is synchronised by a lock mechanism.

When dialog transactions are programmed, locks are set and released by calling certain function modules. These function modules are generated automatically from the definition of so-called lock objects in the ABAP/4 Dictionary. To synchronize the access to a table by setting and removing locks, a Lock object has to be defined in the ABAP/4 Dictionary. Activating the lock object automatically creates #function modules for setting and removing locks. These function modules must be INCLUDED when programming interactive transactions.

Lock Mechanism : To set locks, a lock object must be defined in the ABAP/4 Dictionary. In this lock object, those tables in which data records are to be LOCKED by calling a lock are determined. All tables included in a lock object must be connected to each other via foreign KEYS. The key fields of the tables in a lock object form the Lock arguments for the tables. The lock arguments are the basis for formulating the logical condition for IDENTIFYING the records to be locked. When activating this lock object, two function modulesB with the namesENQUEUE_ and DEQUEUE_ are generated.

When two users simultaneously attempt to access the same data record, this is synchronised by a lock mechanism.

When dialog transactions are programmed, locks are set and released by calling certain function modules. These function modules are generated automatically from the definition of so-called lock objects in the ABAP/4 Dictionary. To synchronize the access to a table by setting and removing locks, a Lock object has to be defined in the ABAP/4 Dictionary. Activating the lock object automatically creates #function modules for setting and removing locks. These function modules must be included when programming interactive transactions.

Lock Mechanism : To set locks, a lock object must be defined in the ABAP/4 Dictionary. In this lock object, those tables in which data records are to be locked by calling a lock are determined. All tables included in a lock object must be connected to each other via foreign keys. The key fields of the tables in a lock object form the Lock arguments for the tables. The lock arguments are the basis for formulating the logical condition for identifying the records to be locked. When activating this lock object, two function modulesB with the namesENQUEUE_ and DEQUEUE_ are generated.

1. Database View (SE11): Database views are implement an inner join, that is, only records of the primary table (selected via the join operation) for which the corresponding records of the SECONDARY tables also exist are FETCHED. Inconsistencies between primary and secondary table could, therefore, lead to a reduced selection set. In database views, the join conditions can be formulated using equality relationships between any base FIELDS. In the other types of view, they must be taken from existing foreign keys. That is, tables can only be collected in a maintenance or help view if they are linked to one another via foreign keys.
2.  Help View ( SE54): Help views are used to output additional information when the online help system is called. When the F4 button is pressed for a screen field, a check is first made on whether a matchcode is defined for this field. If this is not the CASE, the help view is displayed in which the check table of the field is the primary table. Thus, for each table no more than one help view can be created, that is, a table can only be primary table in at most one help view.
3.  Projection View: Projection views are used to suppress or mask certain fields in a table (projection), thus minimizing the NUMBER of interfaces. This means that only the data that is actually required is exchanged when the database is accessed. A projection view can draw upon only one table. Selection conditions cannot be specified for projection views.
4. Maintenance View ( SE54 ): Maintenance views enable a business-oriented approach to looking at data, while at the same time, making it possible to maintain the data involved. Data from several tables can be summarized in a maintenance view and maintained collectively via this view. That is, the data is entered via the view and then distributed to the underlying tables by the system.

Non-standard conversions from display FORMAT to sap internal format and vice-versa are implemented with so called conversion ROUTINES.

AGGREGATED OBJECTS Views, matchcodes, and lock objects are also called aggregate objects because they are FORMED from several related tables.

Non-standard conversions from display format to sap internal format and vice-versa are implemented with so called conversion routines.

Aggregated Objects Views, matchcodes, and lock objects are also called aggregate objects because they are formed from several related tables.

If the data in one of the base tables of a matchcode ID changes, the matchcode data has to be updated. The UPDATE type STIPULATES when the matchcode is to be updated and how it is to be done. The update type ALSO specifies which method is to be used for Building matchcodes . You must SPECIFY the update type when you define a matchcode ID.

If the data in one of the base tables of a matchcode ID changes, the matchcode data has to be updated. The update type stipulates when the matchcode is to be updated and how it is to be done. The update type also specifies which method is to be used for Building matchcodes . You must specify the update type when you define a matchcode ID.

YES, the NUMBERS 0 to 9 are reserved for us to create our own MATCH Code IDs for a SAP defined MATCHCODE object.

Yes, the numbers 0 to 9 are reserved for us to create our own Match Code IDs for a SAP defined Matchcode object.

A maximum NUMBER of MATCH code Id's that can be DEFINED for one Match code OBJECT is36. A match code Id is a one CHARACTER ID which can be a letter or a number.

A maximum number of match code Id's that can be defined for one Match code object is36. A match code Id is a one character ID which can be a letter or a number.

• MATCH CODE OBJECT
• Match Code ID.

MATCH Code is a tool to help us to search for data records in the system. Match codes are an EFFICIENT and user-friendly search AID where the KEY of a record is UNKNOWN.

Match Code is a tool to help us to search for data records in the system. Match codes are an efficient and user-friendly search aid where the key of a record is unknown.

• By SPECIFYING FIXED VALUES.
• By STIPULATING a VALUE table.

• In the case of a SUBSTRUCTURE, the reference originates in the table itself, in the forma of a STATEMENT include. 
• In the case of an append STRUCTURE, the table itself remains UNCHANGED and the reference originates in the append structure.

• APPEND STRUCTURES and
• CUSTOMIZING INCLUDES.

Nine.

Nine.

• The delivery class controls the degree to which the SAP or the CUSTOMER is responsible for table MAINTENANCE whether SAP provides the table with or without CONTENTS.
• Determines the table type. - determines how the table behaves when it is first installed, at upgrade, when it is TRANSPORTED, and when a client copy is performed.

By specifying technical settings we can control how database TABLES are created in the database. The technical settings ALLOWS us to - optimize storage space requirements

• table access behaviour
• buffering required
• CHANGES to entries logged

By specifying technical settings we can control how database tables are created in the database. The technical settings allows us to - optimize storage space requirements

As a reference table, a system table CONTAINING all the VALID CURRENCIES is assigned or any other table which contains a FIELD with the currency key format. This field is called as a reference field. The assignment of the field containing currency amounts to the reference field is made at runtime. The VALUE in the reference field determines the currency of the amount.

As a reference table, a system table containing all the valid currencies is assigned or any other table which contains a field with the currency key format. This field is called as a reference field. The assignment of the field containing currency amounts to the reference field is made at runtime. The value in the reference field determines the currency of the amount.

In a data MANAGEMENT SYSTEM, the principal functions PERFORMED by the data dictionary are:

• Management of data definitions
• Provision of information for evaluation
• SUPPORT for software DEVELOPMENT
• Support form documentation
• Ensuring that the data definitions are flexible and up-to-date.

In a data management system, the principal functions performed by the data dictionary are:

Data DICTIONARY is a central source of data in a data management system. Its main function is to SUPPORT the. It has details about

• What data is contained?
• What are the attributes of the data?
• What is the relationship EXISTING between the VARIOUS data elements?

Data dictionary is a central source of data in a data management system. Its main function is to support the. It has details about

You can specify the extent SIZES and the tablespace (physical storage area in the database) in which a transparent table is to be stored by SETTING the SIZE category and DATA class.

You can specify the extent sizes and the tablespace (physical storage area in the database) in which a transparent table is to be stored by setting the size category and data class.

Possible ABAP/4 data types:

• C: CHARACTER.
• D: Date, format YYYYMMDD.
• F: Floating-point number in DOUBLE PRECISION (8 bytes).
• I: Integer.
• N: Numerical character string of arbitrary LENGTH.
• P: Amount or counter FIELD (packed; implementation depends on hardware platform).
• S: TIME stamp YYYYMMDDHHMMSS.
• T: Time of day HHMMSS.
• V: Character string of variable length, length is given in the first two bytes.
• X: Hexadecimal (binary) storage.

Possible ABAP/4 data types:

ACCP, CHAR, CLNT, CUKY,CURR, DATS, DEC, FLTP, INT1,INT2, INT4, LANG, LCHR,LRAW, NUMC, PREC, QUAN,RAW ,TIMS, UNIT, VARC.

ACCP, CHAR, CLNT, CUKY,CURR, DATS, DEC, FLTP, INT1,INT2, INT4, LANG, LCHR,LRAW, NUMC, PREC, QUAN,RAW ,TIMS, UNIT, VARC.

Domains, Data ELEMENTS, Tables, Technical SETTINGS for tables, Secondary INDEXES for transparent tables, Structures, Views, MATCHCODE objects, Matchcode IDS, Lock objects.

Domains, Data elements, Tables, Technical settings for tables, Secondary indexes for transparent tables, Structures, Views, Matchcode objects, Matchcode IDs, Lock objects.

A table cluster combines several LOGICAL tables in the ABAP/4 Dictionary. Several logical rows from different cluster tables are BROUGHT together in a SINGLE physical record. The records from the cluster tables assigned to a cluster are thus stored in a single COMMON table in the database.

A table cluster combines several logical tables in the ABAP/4 Dictionary. Several logical rows from different cluster tables are brought together in a single physical record. The records from the cluster tables assigned to a cluster are thus stored in a single common table in the database.

These are logical TABLES which must be ASSIGNED to a table pool when they are defined. Pooled tables can be USED to store control data (such as screen sequences or program PARAMETERS).

These are logical tables which must be assigned to a table pool when they are defined. Pooled tables can be used to store control data (such as screen sequences or program parameters).

A table pool (or pool) is used to COMBINE several logical tables in the ABAP/4 DICTIONARY. The definition of a pool consists of at least two key fields and a LONG argument FIELD (VARDATA).

A table pool (or pool) is used to combine several logical tables in the ABAP/4 Dictionary. The definition of a pool consists of at least two key fields and a long argument field (VARDATA).

The function of the TRANSPORT system and the Workbench Organizer is to MANAGE any changes made to objects of the ABAP/4 DEVELOPMENT Workbench and to transport these changes between different SAP systems.

The function of the transport system and the Workbench Organizer is to manage any changes made to objects of the ABAP/4 Development Workbench and to transport these changes between different SAP systems.

The values SPECIFIED for the SIZE category and data class are mapped to database-specific values VIA control TABLES.

The values specified for the size category and data class are mapped to database-specific values via control tables.

The SIZE CATEGORY DESCRIBES the PROBABLE space requirement of the table in the database.

The Size category describes the probable space requirement of the table in the database.

The DATA CLASS determines in which table SPACE the table is STORED when it is created in the database.

The Data class determines in which table space the table is stored when it is created in the database.

Table:

• Table has an UNDERLYING database table
• Table has a primary KEY
• Table has TECHNICAL ATTRIBUTES

Structure:

• No underlying database table
• No primary key
• No technical attributes

Table:

Structure:

Yes. USE the path UTILITIES – > DIRECT Entry Type

Yes. Use the path Utilities – > Direct Entry Type

No

No

Data ELEMENT: Data Element GIVES semantic attributes like field labels and online DOCUMENTATION

Domain: Domain gives the technical attributes like data type and field LENGTH

Data Element: Data Element gives semantic attributes like field labels and online documentation

Domain: Domain gives the technical attributes like data type and field length

• TABLES
• Domains
• Data elements
• STRUCTURES
• FOREIGN keys

ABAP dictionary is a central DATA management system. Its main FUNCTION is to support the CREATION and management of data definitions.

ABAP dictionary is a central data management system. Its main function is to support the creation and management of data definitions.

The data class signifies a physical area in an underlying database where the table is LOGICALLY stored. Also it throws LIGHT on what KIND of data will be stored in the table. Data class helps us to categorize the table on the basis of type of data stored.

There are THREE important data classes

• APPL0 - Master data - Master data is data which is frequently READ, but rarely updated.
• APPL1 - Transaction data - Transaction data is data which is frequently updated.
• APPL2 - Organizational and customizing data - Organizational und customizing data is data which is defined when the system is initialized and then rarely changed.

The data class signifies a physical area in an underlying database where the table is logically stored. Also it throws light on what kind of data will be stored in the table. Data class helps us to categorize the table on the basis of type of data stored.

There are three important data classes

Technical settings allow you to OPTIMIZE the storage requirements and table access behavior of database tables.

Technical Setting comprises of the following COMPONENTS:

• Data Class: Designates the table to an area in the physical database where similar tables are grouped.
• Size Category: Identifies the amount of disk space that will be REQUIRED to hold the data records for a table in the database.
• Buffering: Determines whether table records will be ACCESSED directly from the database server or from global memory.
• Logging: Creates before and after images of changes to the table of contents. Logging must be activated by the profile when the SYSTEM is started.

Technical settings allow you to optimize the storage requirements and table access behavior of database tables.

Technical Setting comprises of the following components:

There are three options available for table view maintenance:

• DISPLAY/maintenance ALLOWED with restrictions: When this option is selected, the display OPERATION will be only functional, rest all the other operations like INSERT, update and delete will be disabled.
• Display/maintenance allowed: When this option is selected, all KIND of operations (Insert, Update, Delete and Display) can be performed on the table.
• Display/maintenance not allowed: When this option is selected, no operation including display table contents can be performed on the table.

There are three options available for table view maintenance:

Delivery Class manages the transport of table data when installing or upgrading in a client copy when transporting between customer systems.

Different delivery classes available are:

• C - Customizing table, MAINTENANCE only by customer not SAP import.
  Example: COMMON Address Data (Country: T005)
• E - Control table, SAP and customer have separate key areas, defined in TRESC
  Example: Messages (T100)
• G - Customizing table, protected against SAP Upgrade
  Example: Communication: country dialing CODE (T005K)
• L - Table for storing temporary data, delivered empty
  Example: Lock Arguments (E070USE)
• S - System table maintenance only by SAP.
  Example: LANGUAGE Key (T002)
• A - Application table (master and transaction data)
  Example: Personal Address Data, Username (USR01)
• W - System table, contents transportable via separate TR objects.
  Example: Transport (E070), Tables (DD02L)

Delivery Class manages the transport of table data when installing or upgrading in a client copy when transporting between customer systems.

Different delivery classes available are:

There are three operations that can be PERFORMED on views in SAP: Join, Projection and Selection.

• The Projection OPERATION is used to narrow a view’s focus to certain fields in a table.
• The Selection Operation is used to narrow a view’s focus to certain records in a table.
• The Join Operation is used to combine information from MULTIPLE tables into a single view.

There are three operations that can be performed on views in SAP: Join, Projection and Selection.

The BASIC differences between projection view and DATABASE view are:

• Database view can built over many tables whereas projection view can be built over a single table only.
• Database view can be updated if the view is built over a single table whereas in projection view data can be updated.
• In case of database view, data updates can USE open SQL or native SQL whereas in case of projection view, data updates MUST use open SQL.
• Database view can be BUFFERED whereas Projection view cannot be buffered.

The basic differences between projection view and database view are:

Help views can be used as SELECTION methods for Search HELPS. It MIGHT be necessary to create a Help View if you are trying to accomplish an OUTER join, since database views only create INNER joins.

Help views can be used as selection methods for Search Helps. It might be necessary to create a Help View if you are trying to accomplish an outer join, since database views only create inner joins.

Just like we have table maintenance (SM30) for each table, similarly if there is a requirement to maintain DATA for one or more tables in a single view, then maintenance view can be created. All the tables in a maintenance view must be linked with foreign key. The join CONDITIONS for maintenance views are always derived from the foreign key AUTOMATICALLY and THUS one cannot directly enter the join conditions as for database views. Unlike Database views, one can modify data from maintenance view.

Thus, a maintenance view allows you to maintain the data of an application object together. 

Just like we have table maintenance (SM30) for each table, similarly if there is a requirement to maintain data for one or more tables in a single view, then maintenance view can be created. All the tables in a maintenance view must be linked with foreign key. The join conditions for maintenance views are always derived from the foreign key automatically and thus one cannot directly enter the join conditions as for database views. Unlike Database views, one can modify data from maintenance view.

Thus, a maintenance view allows you to maintain the data of an application object together. 

In standard SAP tables ONE can find there are a number of fields. Sometimes it happens or there is a requirement of viewing only a fewer no of fields of a table, in such cases a projection VIEW can be created. Projection views are created only on a single table.

For example, if Table T1 has fields F1,F2,F3,F4,F5, F6, F7, F8, F9, F10, etc…

Say there is a need to view data only for say Fields F1, F2, F4,F8 & F9, in such cases projection view can be created.

In standard SAP tables one can find there are a number of fields. Sometimes it happens or there is a requirement of viewing only a fewer no of fields of a table, in such cases a projection view can be created. Projection views are created only on a single table.

For example, if Table T1 has fields F1,F2,F3,F4,F5, F6, F7, F8, F9, F10, etc…

Say there is a need to view data only for say Fields F1, F2, F4,F8 & F9, in such cases projection view can be created.

The database view is COMBINING several fields of TWO or more tables into single table. At least one relationship is required is required to combine tables to build a database view. Plus one can only read DATA from database view and cannot MODIFY the data in the view directly (if view involves more than one table). Database views implement an Inner Join on the tables. The database view is the only type of view in SAP that is physically created at the database level. 

For example, consider two tables T1, T2.

Fields of table T1 are F1, F2 and F3. Fields of table T2 are F1, F5.

By using a Database view one can combine the fields of both tables T1 and T2, provided primary and foreign KEY relation is maintained between the two tables and thus final view can have fields like F1, F2, F3, F5.

The database view is combining several fields of two or more tables into single table. At least one relationship is required is required to combine tables to build a database view. Plus one can only read data from database view and cannot modify the data in the view directly (if view involves more than one table). Database views implement an Inner Join on the tables. The database view is the only type of view in SAP that is physically created at the database level. 

For example, consider two tables T1, T2.

Fields of table T1 are F1, F2 and F3. Fields of table T2 are F1, F5.

By using a Database view one can combine the fields of both tables T1 and T2, provided primary and foreign key relation is maintained between the two tables and thus final view can have fields like F1, F2, F3, F5.

In SAP, you have total four types of views. Based on the WAY in which the VIEW is implemented and the methods that are permitted for ACCESSING the view data they are divided into Database View, Projection View, Maintenance View and Help View. 

Database views implement an Inner Join whereas Projection View, Maintenance View and Help View implement an Outer Join.

There are 4 DIFFERENT types of Views in SAP. They are:

• Maintenance View
• Database View
• Projection View
• Help View

In SAP, you have total four types of views. Based on the way in which the view is implemented and the methods that are permitted for accessing the view data they are divided into Database View, Projection View, Maintenance View and Help View. 

Database views implement an Inner Join whereas Projection View, Maintenance View and Help View implement an Outer Join.

There are 4 Different types of Views in SAP. They are:

A view is like a telescope which just provides a picture of something. You can construct a view with special lenses or filters to allow you to look at one or more dictionary tables. You can look at parts of one table (selected records and/or fields) or combinations of tables and parts of tables. A view is an ABAP Dictionary object. In simple words, a View simply mirrors an entire database table. A view WOULD just look like a table and ACT just like a table – but it isn't actually a table.

A view does not contain DATA of its own - rather, the view provides SPECIALIZED access to the data that exists in other tables. For this reason, views are often called virtual tables. Views are used to look into one or more tables. A view does not contain data of its own.

Views combines more than one table. The structure of the view is defined in the ABAP Dictionary. With the help of views, application-dependent view can be defined that combines the data.

Data about an application object (like Purchase order, Sales Order, Invoice VERIFICATION, etc.) is often distributed on several database tables. By defining a view, one can define an application-dependent view that combines this data. The structure of such a view is defined by specifying the tables and fields used in the view. Fields that are not required can be hidden, thereby minimizing interfaces. A view can be used in ABAP programs for data selection.

A view is like a telescope which just provides a picture of something. You can construct a view with special lenses or filters to allow you to look at one or more dictionary tables. You can look at parts of one table (selected records and/or fields) or combinations of tables and parts of tables. A view is an ABAP Dictionary object. In simple words, a View simply mirrors an entire database table. A view would just look like a table and act just like a table – but it isn't actually a table.

A view does not contain data of its own - rather, the view provides specialized access to the data that exists in other tables. For this reason, views are often called virtual tables. Views are used to look into one or more tables. A view does not contain data of its own.

Views combines more than one table. The structure of the view is defined in the ABAP Dictionary. With the help of views, application-dependent view can be defined that combines the data.

Data about an application object (like Purchase order, Sales Order, Invoice Verification, etc.) is often distributed on several database tables. By defining a view, one can define an application-dependent view that combines this data. The structure of such a view is defined by specifying the tables and fields used in the view. Fields that are not required can be hidden, thereby minimizing interfaces. A view can be used in ABAP programs for data selection.

Differences between transparent, pooled and cluster tables are:

• Transparent tables have a ONE to one relationship with a physical table in an UNDERLYING database where as pooled tables and cluster tables have many to one relationship with a physical table in the underlying database (Relationship between tables in ABAP Dictionary & Underlying database).
  
  For each transparent table there will be exactly only one table in the underlying database whereas many pooled tables are stored in a single table in an underlying database called table pool. Similarly many cluster tables are stored in a single table in the database called a table cluster
• In case of transparent tables, the underlying database table will have the same name, same number of fields and the fields will also have the same names as defined in ABAP Dictionary whereas for pooled tables and cluster tables the underlying database table will have DIFFERENT name, different number of fields and fields will have different names from what has been defined in ABAP Dictionary.
• Transparent tables can have one or more primary key Whereas Primary key of each pooled table of a table pool need not be same whereas Primary key of each cluster table of a table cluster should have at least one key in common.
• Secondary indexes can be created for transparent tables, but for pooled and cluster tables we cannot create any secondary index.
• Transparent tables can be accessed via both Native and Open SQL whereas pooled and cluster table can be accessed by Open SQL only.

Transparent tables are used to hold application data which includes both master data as well as transaction data. 

Pooled tables REDUCE the amount of database resources needed when many small tables have to be opened at the same TIME.

Cluster tables are used when the tables have primary key in common and data in these tables are all accessed simultaneously.

Differences between transparent, pooled and cluster tables are:

Transparent tables are used to hold application data which includes both master data as well as transaction data. 

Pooled tables reduce the amount of database resources needed when many small tables have to be opened at the same time.

Cluster tables are used when the tables have primary key in common and data in these tables are all accessed simultaneously.