CONSITENCEY THROUGH INPUT CHECKS:
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.
In order to define the foreign key, these three fields are assigned to fields of the foreign key table (foreign key fields) with which the input to be checked is entered on the screen. In table SBOOK these are the fields: MANDT, CARRID, COUNTER. The entry is accepted if it represents a valid counter; otherwise the system will reject it.
The foreign key is defined for field SBOOK-COUNTER (check field), which means that the entry in this field is checked. Field COUNTER is therefore called the check field for this foreign key.
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.
CAUTION!
The constellation that a domain that itself has table SAIRPORT as value table is used following field SAIRPORT-Airport is correct !! However, a foreign key is never defined on this field (avoiding a loop).
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.
Only one text table can be created for a table.
RELATED POSTS
Subscribe to:
Post Comments (Atom)
Content
-
▼
2009
(120)
-
▼
March
(87)
- WORK FLOW SCENARIOS IN SD SAP II
- WORK FLOW SCENARIOS IN SD SAP I
- WORK FLOW SAP IV
- WORK FLOW SAP III
- WORK FLOW SAP II
- WORK FLOW SAP I
- BDC SAP X
- BDC SAP IX
- BDC SAP VIII
- BDC SAP VII
- BDC SAP VI
- BDC SAP V
- BDC SAP IV
- BDC SAP III
- BDC SAP II
- BDC SAP I
- BADI SAP III
- BADI SAP II
- BADI SAP I
- BAPI SAP IV
- BAPI SAP III
- BAPI SAP II
- BAPI SAP I
- TABLE CONTROL IN BDC
- USER EXITS IN DETAIL
- BDC AND LSMW COMPARISION
- MODIFICAITONS EXITEDED 57
- SAP MODIDICAITONS 56
- BUSINESS ADD INS 55
- BUSINESS TRANSACTION EVENTS 53
- ENHANCEMENTS USING COSTMER EXITS 54
- ENHANCEMENTS TO DICTIONERY ELEMENTS 52
- CHANGING THE SAP STANDARD 51
- AUTHORISATION CHECKS 50
- COMPLEX LUW PROCESSING 49
- ORGANIZING DATA BASE UPDATES 48
- SAP LOCK CONCEPT 47
- LUW’S AND CLIENT/SERVER ARCHITECHERE 46
- OVERVIEW OF DATABAE UPDATES XXXXV
- LISTS IN SCREEN PROGRAMMING XXXXIV
- CONTEXT MENUS ON SCREENS XXXXIII
- SCREEN ELEMENTS ANDTABLE CONTROLS XXXXII
- SUBSCREEN TABSTRIPS XXXXI
- SCREEN ELEMENTS FOR INPUT AND OUTPUT XXXX
- SCREEN ELEMENTS FOR OUTPUT XXXIX
- IDOC AND BAPI
- DIFFERENCE BETWEEN CONVERSION AND INTERFACE
- INTRODUCITON TO SCREEN PROGRAMMING XXXVIII
- INTERACTIVE LIST TECHNIQUES XXXVII
- SAP LANDSCAPE
- PROGRAM INTERFACE XXXVI
- BASICS OF INTERACTIVE REPORTS XXXV
- ALV GRID CONTROL XXXIV
- SAVING LISTS AND BACK GROUND PROCESSING XXXIII
- DATA FORMATTING AND CONTROL LEVEL PROCESSING XXXII
- SAP QUARY ADMINSTRATION XXXI
- PROGRAMMING DATA RETRIVAL XXX
- LOGICAL DATA BASES XXVIII
- SELECTION SCREENS ABAP REPORT XXIX
- ALV DOCUMENTATION COMPLETE
- FAQ'S ON ABAP CROSS APPLICATIONS
- TECHNIQUES FOR LIST CREATION AND SAP QUARY XXVI
- CALLING PROGRAM AND PASSING DATA XXV
- FUNCTION MODULES AND GROUPS OF ABAP XXIV
- SUB ROUTIENS IN ABAP XXIII
- INTERNAL TABLES IN ABAP XXII
- ABAP STATEMENTS XXI
- DATA TYPES AND DATA OBJECT XX
- ABAP RUN TIME ENVIRONMENT XIX
- SEARCH HELP XVIII
- VIEWS IN ABAP XVII
- CHANGES TO DATA BASE TABLES XVI
- DEPENDENCIES OF DICTIONARY OBJECTS XV
- CONSITENCEY THROUGH INPUT CHECKS XIV
- PERFORMANCE DURING TABLE ACCESS XIII
- ABAP DICTIONARY XII
- ABAP PROJECT OVERVIEW - XI
- REUSE COMPONENTS - X
- DIALOGS AND SCREENS - IX
- USER DIALOGS AND SELECTION SCREEN - VIII
- USER DIALOGS-LISTS - VII
- INTERNAL PROGRAM MODULARIZATION - VI
- DATA BASE DIALOG - V
- ABAP DATA OBJECTS AND STATEMENTS - IV
- ABAP WORK BENCH AND TOOLS - III
- SAP ARCHETECHERE AND DESIGN - II
- SAP NAVIGATION - I
-
▼
March
(87)
Privacy Policy
The articles are copyrighted to Technical Information and can only
be reproduced given the author's permission.Information furnished
in the blog is collected from various Resources.This blog does not
host any files on its server. Please report any broken links in
comment.
If u have any queries contact me at
technicalinformation.websites@gmail.com
0 comments:
Post a Comment