You are on page 1of 16


Choose a database table name & then press create button.


customized table .now click on the delivery class and choose the 2nd option i.e.

now click the save button on the top of the scren .

in the new window click on the local object. .

now click the GOTO link and choose technical settings. .

give the size category(0-4 .click on the dataclass and choose APPL2.0 is given here) .

.now click the save button. and then the back button.

======================================== ======================================== INFORMATION FROM THE TEXT FIELDS 1st Page> .Now click the active button.

. Foreign keys: The foreign keys define the relationships between this table and other tables. Indexes: Indexes can be defined for the table to speed up data selection from the table. The fields of the table are defined together with their (database-independent) data types and lengths. 16 characters Database table Tables can be defined independently of the database in the ABAP Dictionary. There are three categories of database tables in the ABAP Dictionary.a>database table name ----------------------------Table name. Technical settings: The technical settings define how the table is created on the database. A table definition in the ABAP Dictionary has the following components: • • • • Table fields: The field names and the data types of the fields contained in the table are defined here.

The structure of such a view is defined by specifying the tables and fields involved in the view. a view is not actually physically stored. b>view Name of an SAP table view. The table definition is translated from the ABAP Dictionary to a definition of the particular database. More complicated views can be assembled from several tables. number of places) and information that is relevant for the screen (such as title) of unstructured data objects (variables/fields). c>datatype Name of Dictionary type User-defined types in the ABAP Dictionary You can define any user-defined types in the ABAP Dictionary. Use Logical views for the application permitting direct access to the data can be generated with the definition of view. The data of these tables is stored in the corresponding table pool or table cluster. this derivation process can involve simply suppressing the display of one or more fields from a table (projection) or transferring only certain records from a table to the view (selection). A table can also be used as a component in a structure. Structures (structured types) Structured types describe the structure and functions of any structured data objects. 16 characters A view is a logical view on one or more tables. In the simplest case. pooled tables and cluster tables are not created in the database. that is. They describe the data type attributes (such as given Dictionary data type. with individual tables being linked using the relational join operation. On the other hand. These can be used in the ABAP program to define data objects and types analogously to types that are predefined in the ABAP program (such as C or I) or types that are defined locally in ABAP programs.A physical table definition is created in the database for the table definition stored in the ABAP Dictionary for transparent tables when the table is activated. The following type categories can be defined in the ABAP Dictionary: • Data elements (elementary types) Elementary types have no structure. It is not necessary to create indexes and technical settings for pooled and cluster tables. instead being derived from one or more other tables. • . A component can be a field with an elementary type or can itself be a structure. that is of data structures with components of any type.

This ensures the consistency of these fields. The options for creating types with structured types and table types can be combined as required. the fields of a database table can only have an elementary type. The central definition of types that are used more than once in the ABAP Dictionary allows them to be changed centrally. such as the data type or the number of positions in a field.A database table always has a structure and is therefore implicitly a structured type. For example. In this way you can define any complex types globally in the ABAP Dictionary and use them in ABAP programs. .g. The runtime object permits very efficient access to the relevant information for the type in compressed form. for example. d>Type group e> domain Name of a domain with Set/Get parameter A domain describes the technical attributes of a field. These changes are made at all the relevant locations by the active ABAP Dictionary. ABAP programs adjust to the changed type definitions when they are recreated. types or tables) that use this type are automatically adjusted to the change at activation. • Table types Table types describe the structure and functions of internal tables in the ABAP program. However. therefore may not have the same name as a structure. Their rows can have any row type. A data element. the local types shadow the types of the type groups and the types defined globally in the Dictionary. The domain defines primarily a value range describing the valid data values for the fields referring to this domain. Different technical fields of the same type can be combined in a domain. all the objects (e. a type defined in an ABAP program and a Dictionary type may have the same name. Fields referring to the same domain are changed at the same time when a domain is changed. When a type is changed. The following shadowing rule is valid when using types in ABAP programs: If the names are identical. However. The runtime object of the Dictionary type (nametab) is the interface for their use in ABAP programs. All Dictionary types lie in a common namespace. Table types with elementary row type therefore can be defined just the same as multi-dimensional table types (table types with a table type as row type) or table types using structures with table-like components.

Append search helps can be used to enhance collective search helps delivered by SAP with customer-specific search paths without requiring a modification. The dialog behavior and data collection are defined differently for elementary search helps and collective search helps. The outer interface is defined by specifying the interface parameters . g>lock object Lock object name A lock object is a virtual link of several SAP tables which is used to synchronize simultaneous access by two users to the same set of data ( SAP lock concept). The search help attachment defines the field contents for parametrizing an import parameter and the fields of the input template in which the contents of the export parameters should be returned. the online behavior and the method of data collection. A collective search help therefore provides several alternative search paths for possible entries. The behavior of a search help can be made more flexible than usual with search help exits. . The three components of the input help process described by a search help are the outer interface. Collective search helps contain several elementary search helps.f>search help Name of a search help A search help is an object of the ABAP Dictionary with which input helps (F4 helps) can be defined. They define the context information to be used in the input help process and the attributes to be sent to the screen by the input help. There are the following types of search helps: • • • Elementary search helps implement a search path for determining the possible entries.

The function modules for requesting and releasing locks which are created automatically when the lock object is activated must be linked to the programming of the relevant online transactions. 2>PAGE 2 a>delivery class Delivery class . These lock objects must be explicitly created in the ABAP Dictionary. you must perform the following steps: 1. You must define a lock object in the ABAP Dictionary.Locks are requested and released in the programming of online transactions by calling certain function modules which are automatically generated from the definition of the lock objects. To set locks. 2. The name of the lock object should begin with E.

Existing data records are overwritten. (Use Report RDDKOR54 here). data is maintained by the customer only.) S: System table. Classes W. The delivery class is also used in the extended table maintenance. Normally it does not make sense to transport such data.The delivery class controls the transport of table data when installing or upgrading. but is supported to permit you to copy an entire client environment. L: Table for storing temporary data.g. but existing data records are not overwritten.). W: System table (e. Classes E. E: System table with its own namespaces for customer entries. There are the following delivery classes: • • • • A: Application table (master and transaction data). but may not overwrite or delete existing data records. In all other clients. table of the development environment) whose data is transported with its own transport objects (e. . S: The data records of the table are copied to the target client. R3TR PROG. in a client copy and when transporting between customer systems. Class G: Existing data records are overwritten in client 000. The customer namespace must be defined in table TRESC. upgrade and language import The behavior differs here for client-specific and cross-client tables. data changes have the same status as program changes. SAP may insert new data records. E. L: The data records of the table are not copied to the target client. Existing data records are overwritten. new data records are inserted. Class L: No data is imported. The customer namespace must be defined in table TRESC. etc. • • • Behavior during client copy Only the data of client-specific tables is copied. G: Customer table. Behavior during installation. Class A: Data records are only copied to the target client if explicitly requested (parameter option).g. S and W: Data is imported into all clients. C: Customer table. Client-specific tables • • • • Classes A and C: Data is only imported into client 000. • • • Classes C. (Use Report RDDKOR54 here. R3TR TABL. G.

If the data violates the namespace. Note: The indicator is not available for help views since they are not relevant to SE54 and are used for search functions. . L and C: No data is imported. Behavior during transport between customer systems Data records of tables of delivery class L are not imported into the target system. Usage The indicator can have the following values: • Display/maintenance not allowed The usage of standard table maintenance tools is not allowed.Cross-client tables • • • Classes A. Classes E. S. maintenance views. The maintenance interface generated for a table makes the following checks: • • You cannot transport the entered data with the transport link of the generated maintenance interface for tables of delivery classes W and L. but existing data records are not overwritten. S and W are imported into the target system (this is done for the target client specified in the transport for client-specific tables). Use of the delivery class in the extended table maintenance The delivery class is also analyzed in the extended table maintenance (SM30). When you enter data. b>data browser Flag if Maintenance with Standard Tools is allowed Definition This indicator specifies whether it is possible to display/maintain a table/view using the maintenance tools Data Browser (transaction SE16) and table view maintenance (transactions SM30 and SM31). Classe G: Data records that do not exist are inserted. Exisitng data records with the same key are overwritten. projection views. The indicator can be set for database views. C. and tables (called 'Table/ View' below) using transaction SE11. the input is rejected. G. mantenance view variants. there is a check if this data violates the namespace defined for the table in table TRESC. Data records of tables of delivery classes A. E. and W: Data is imported.

Transaction SM30 does not allow maintenance and display functions for this table/view. • Display/maintenance allowed The usage of standard table maintenance tools is allowed: o Transaction SE16 allows the maintenance and display functions for this table/view. Note: The generated dialog can be included in view clusters (data maintenance through transaction SM34) or called within a program through the function module View_Maintenance_Call.o o Maintenance and display of this table/view is not possible in transaction SE16. Generation of a maintenance dialog for this table/view is possible through transaction SE54. this is called. When the standard maintenance tools are used. Note: The generated dialog can be included in view clusters (data maintenance through transaction SM34) or called through the function module View_Maintenance_Call in the same way as the transaction call SM30. o o Transaction SE54 allows the generation of a maintenance dialog for this table/view. . This is rejected in the option 'Display/maintenance not allowed'. which means automatically that calling transactions SM30/SM34 for this table/view is no longer possible. the system checks the corresponding authorizations of the user. but no maintenance. Transaction SM30 allows the display and maintenance functions for this table/view. 'Display/maintenance not allowed' does not apply since maintenance views and maintenance view variants serve exclusively to generate a user interface. • Display/maintenance allowed to limited extent Usage of standard table maintenance tools is allowed to a limited extent: o o o Transaction SE16 allows the display function for this table/view. Note: If an SM30 maintenance dialog exists. Comment Only the last two options are offered for maintenance views and maintenance view variants. Transaction SE54 does not allow the generation of a maintenance dialog.