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
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
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 :
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:
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
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:
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:
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
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
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
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
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!
EDITOR CALL PART ONE
EDITOR CALL PART TWO
ELSE AND ELSE-IF
EXEC
EXPORT PART ONE
EXPORT PART TWO
FETCH
FIELD SYMBOLS
Subscribe to:
Posts (Atom)
