****EXE PROGRAM-****
REPORT ZREPORT .
***TABLE WORK AREA****
TABLES:KNA1,VBAK.
***INTERNAL TABLE***
DATA:ITAB TYPE VBAK OCCURS 0,
****LOGIC FOR CUTOM CONTROL OF SCREEN 100 ****
CONTAINER TYPE SCRFNAME VALUE 'LVCONTROL',
CUST TYPE REF TO CL_GUI_CUSTOM_CONTAINER,
TREE TYPE REF TO CL_GUI_ALV_TREE_SIMPLE,
Read the complete post here.
RELATED POSTS
Customer Relationship Management and mysap an introduction
CRM Management and sales and service strategy of mysap crm
MySAP CRM and customer as business partner
How Customer Relationship management makes company Leader
CRM Uses and how to get best results with CRM
SAP TABLES
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
MODIFICAITONS TO SAP DAY 56
MODIFICATIONS TO SAP EXTENDED DAY 57
Master data for sap
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
MODIFICAITONS TO SAP DAY 56
MODIFICATIONS TO SAP EXTENDED DAY 57
Master data for sap
TABLE TYPES IN ABAP
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
CHANGING THE SAP STANDARD DAY 51
ENHANCEMENTS TO ABAP DICTIONARY DAY 52
BUSINESS TRANSACTION EVENTS IN SAP DAY 53
ENHANCEMENTS USING CUSTOMER EXITS DAY 54
BUSINESS ADD-IN'S IN SAP DAY 55
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
CHANGING THE SAP STANDARD DAY 51
ENHANCEMENTS TO ABAP DICTIONARY DAY 52
BUSINESS TRANSACTION EVENTS IN SAP DAY 53
ENHANCEMENTS USING CUSTOMER EXITS DAY 54
BUSINESS ADD-IN'S IN SAP DAY 55
SELECTION METHOD ON SEARCH HELP IN ABAP
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
LWS AND CLINET SERVER DAY 46
SAP LOCK CONCEPT DAY 47
ORGANIZING DATA BASE UPDATS DAY 48
COMPLEX LUW PROCESSING DAY 49
AUTHORIZATION CHECKS IN ABAP DAY 50
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
LWS AND CLINET SERVER DAY 46
SAP LOCK CONCEPT DAY 47
ORGANIZING DATA BASE UPDATS DAY 48
COMPLEX LUW PROCESSING DAY 49
AUTHORIZATION CHECKS IN ABAP DAY 50
SEARCH HELP IN ABAP
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....... Read the complete post here.
SCREEN ELEMENTS AND SUB SCREENS DAY 41
SCREEN ELEMENTS IN TABLE DAY 42
CONTEXT MENU IN THE SCREEN DAY 43
LISTS IN SCREEN PROGRAMMING DAY 44
DATA BASE UPDATAS AN OVERVIEW DAY 45
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....... Read the complete post here.
SCREEN ELEMENTS AND SUB SCREENS DAY 41
SCREEN ELEMENTS IN TABLE DAY 42
CONTEXT MENU IN THE SCREEN DAY 43
LISTS IN SCREEN PROGRAMMING DAY 44
DATA BASE UPDATAS AN OVERVIEW DAY 45
INNER AND OUTER JOINS IN ABAP
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
PROGRAM INTERFACE AN INTRODUCTION DAY 36
INTERACTIVE REPORT LIST TECHNIQUES DAY 37
SCREEN PROGRAMMING AN INTRODUCTION DAY 38
SCREEN ELEMENTS FOR OUTPUT ABAP REPORT DAY 39
SCREEN ELEMENTS FOR INPUT DAY 40
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
PROGRAM INTERFACE AN INTRODUCTION DAY 36
INTERACTIVE REPORT LIST TECHNIQUES DAY 37
SCREEN PROGRAMMING AN INTRODUCTION DAY 38
SCREEN ELEMENTS FOR OUTPUT ABAP REPORT DAY 39
SCREEN ELEMENTS FOR INPUT DAY 40
ABAP VIEWS
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
SAP QUARY ADMISTRATION DAY 31
DATA FORMATION FOR OUTPUT DAY 32
SAVING LISTS IN BACK GROUND DAY 33
ALV GRID CONTROL IN REPORTS DAY 34
INTERACTIVE REPORTS BASICS DAY 35
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
SAP QUARY ADMISTRATION DAY 31
DATA FORMATION FOR OUTPUT DAY 32
SAVING LISTS IN BACK GROUND DAY 33
ALV GRID CONTROL IN REPORTS DAY 34
INTERACTIVE REPORTS BASICS DAY 35
APPEND STRUCTURE
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
TECHNIQUES FOR LIST CREATION DAY 26
LOGICAL DATA BASES LDB DAY 28
SELECTOIN SCREEN FOR ABAP PROGRAM DAY 29
PROGRAMMING DATA RETRIVAL IN ABAP DAY 30
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
TECHNIQUES FOR LIST CREATION DAY 26
LOGICAL DATA BASES LDB DAY 28
SELECTOIN SCREEN FOR ABAP PROGRAM DAY 29
PROGRAMMING DATA RETRIVAL IN ABAP DAY 30
CHANGES TO DATA BASE TABLES
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
ABAP STATEMENTS DAY 21
ROLE OF INTERNAL TABLE IN ABAP DAY 22
ABAP SUB ROUTINES DAY 23
FUNCTION GROUPS AND FUNCTION MODULES IN ABAP DAY 24
CALLING PROGRAMS AND PASSING DATA IN SAP DAY 25
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
ABAP STATEMENTS DAY 21
ROLE OF INTERNAL TABLE IN ABAP DAY 22
ABAP SUB ROUTINES DAY 23
FUNCTION GROUPS AND FUNCTION MODULES IN ABAP DAY 24
CALLING PROGRAMS AND PASSING DATA IN SAP DAY 25
Subscribe to:
Posts (Atom)