Вы находитесь на странице: 1из 16

HOW TO CREAT A TABLE IN ABAP

1>

Choose a database table name & then press create button.

2>
now click on the delivery class and choose the 2nd option i.e. customized table
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.
click on the dataclass and choose APPL2, give the size
category(0-4 ,0 is given here)
now click the save button, and then the back button.
Now click the active button.

========================================
========================================
INFORMATION FROM THE TEXT FIELDS

1st Page>
a>database table name
-----------------------------
Table name, 16 characters

Database table
Tables can be defined independently of the database in the ABAP Dictionary. The fields of the table are
defined together with their (database-independent) data types and lengths.

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.

• Foreign keys: The foreign keys define the relationships between this table and other tables.

• Technical settings: The technical settings define how the table is created on the database.

• Indexes: Indexes can be defined for the table to speed up data selection from the table.

There are three categories of database tables in the ABAP Dictionary.


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 table definition is translated from the ABAP Dictionary to
a definition of the particular database.

On the other hand, pooled tables and cluster tables are not created in the database. The data of these
tables is stored in the corresponding table pool or table cluster. It is not necessary to create indexes and
technical settings for pooled and cluster tables.

b>view
Name of an SAP table view, 16 characters
A view is a logical view on one or more tables, that is, a view is not actually physically stored, instead being
derived from one or more other tables.

In the simplest case, 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). More
complicated views can be assembled from several tables, with individual tables being linked using the
relational join operation.

Use
Logical views for the application permitting direct access to the data can be generated with the definition of
view. The structure of such a view is defined by specifying the tables and fields involved in the view.

c>datatype
Name of Dictionary type

User-defined types in the ABAP Dictionary


You can define any user-defined types in the ABAP Dictionary. 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.

The following type categories can be defined in the ABAP Dictionary:

• Data elements (elementary types)


Elementary types have no structure. They describe the data type attributes (such as given
Dictionary data type, number of places) and information that is relevant for the screen (such as title)
of unstructured data objects (variables/fields).

• Structures (structured types)


Structured types describe the structure and functions of any structured data objects, that is of data
structures with components of any type.
A component can be a field with an elementary type or can itself be a structure. A table can also be
used as a component in a structure.
A database table always has a structure and is therefore implicitly a structured type. However, the
fields of a database table can only have an elementary type.

• Table types
Table types describe the structure and functions of internal tables in the ABAP program. Their rows
can have any row type. 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.

The options for creating types with structured types and table types can be combined as required. In this
way you can define any complex types globally in the ABAP Dictionary and use them in ABAP programs.
The runtime object of the Dictionary type (nametab) is the interface for their use in ABAP programs. The
runtime object permits very efficient access to the relevant information for the type in compressed form.

The central definition of types that are used more than once in the ABAP Dictionary allows them to be
changed centrally. These changes are made at all the relevant locations by the active ABAP Dictionary.
For example, ABAP programs adjust to the changed type definitions when they are recreated. When a type
is changed, all the objects (e.g. types or tables) that use this type are automatically adjusted to the change
at activation.

All Dictionary types lie in a common namespace. A data element, for example, therefore may not have the
same name as a structure. However, a type defined in an ABAP program and a Dictionary type may have
the same name.

The following shadowing rule is valid when using types in ABAP programs:
If the names are identical, the local types shadow the types of the type groups and the types defined globally
in the Dictionary.

d>Type group

e> domain
Name of a domain with Set/Get parameter
A domain describes the technical attributes of a field, such as the data type or the number of positions in a
field. 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. Fields referring to the same domain
are changed at the same time when a domain is changed. This ensures the consistency of these fields.
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.

There are the following types of search helps:

• Elementary search helps implement a search path for determining the possible entries.

• Collective search helps contain several elementary search helps. A collective search help
therefore provides several alternative search paths for possible entries.

• Append search helps can be used to enhance collective search helps delivered by SAP with
customer-specific search paths without requiring a modification.

The three components of the input help process described by a search help are the outer interface, the
online behavior and the method of data collection.

The outer interface is defined by specifying the interface parameters . 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.

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 dialog behavior and data collection are defined differently for elementary search helps and collective
search helps.

The behavior of a search help can be made more flexible than usual with search help exits.

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).
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. These lock objects must
be explicitly created in the ABAP Dictionary.

To set locks, you must perform the following steps:

1. You must define a lock object in the ABAP Dictionary. The name of the lock object should begin
with E.
2. 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
The delivery class controls the transport of table data when installing or upgrading, in a client copy and when
transporting between customer systems. The delivery class is also used in the extended table maintenance.

There are the following delivery classes:

• A: Application table (master and transaction data).

• C: Customer table, data is maintained by the customer only.

• L: Table for storing temporary data.

• G: Customer table, SAP may insert new data records, but may not overwrite or delete existing data
records. The customer namespace must be defined in table TRESC. (Use Report RDDKOR54
here).

• E: System table with its own namespaces for customer entries. The customer namespace must be
defined in table TRESC. (Use Report RDDKOR54 here.)

• S: System table, data changes have the same status as program changes.

• W: System table (e.g. table of the development environment) whose data is transported with its
own transport objects (e.g. R3TR PROG, R3TR TABL, etc.).

Behavior during client copy


Only the data of client-specific tables is copied.

• Classes C, G, E, S: The data records of the table are copied to the target client.

• Classes W, L: The data records of the table are not copied to the target client.

• Class A: Data records are only copied to the target client if explicitly requested (parameter option).
Normally it does not make sense to transport such data, but is supported to permit you to copy an
entire client environment.

Behavior during installation, upgrade and language import


The behavior differs here for client-specific and cross-client tables.

Client-specific tables
• Classes A and C: Data is only imported into client 000. Existing data records are overwritten.

• Classes E, S and W: Data is imported into all clients. Existing data records are overwritten.

• Class G: Existing data records are overwritten in client 000. In all other clients, new data records
are inserted, but existing data records are not overwritten.

• Class L: No data is imported.


Cross-client tables
• Classes A, L and C: No data is imported.

• Classes E, S, and W: Data is imported. Exisitng data records with the same key are overwritten.

• Classe G: Data records that do not exist are inserted, but existing data records are not overwritten.

Behavior during transport between customer systems


Data records of tables of delivery class L are not imported into the target system. Data records of tables of
delivery classes A, C, E, G, 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). 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.

• When you enter data, there is a check if this data violates the namespace defined for the table in
table TRESC. If the data violates the namespace, the input is rejected.

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).

The indicator can be set for database views, projection views, maintenance views, mantenance view
variants, and tables (called 'Table/ View' below) using transaction SE11.

Note: The indicator is not available for help views since they are not relevant to SE54 and are used for
search functions.

Usage
The indicator can have the following values:

• Display/maintenance not allowed

The usage of standard table maintenance tools is not allowed.


o Maintenance and display of this table/view is not possible in transaction SE16.

o Transaction SE54 does not allow the generation of a maintenance dialog, which means
automatically that calling transactions SM30/SM34 for this table/view is no longer
possible.

• Display/maintenance allowed to limited extent

Usage of standard table maintenance tools is allowed to a limited extent:

o Transaction SE16 allows the display function for this table/view, but no maintenance.

o Generation of a maintenance dialog for this table/view is possible through transaction


SE54.

o Transaction SM30 does not allow 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.

• 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: If an SM30 maintenance dialog exists, this is called.

o Transaction SE54 allows the generation of a maintenance dialog for this table/view.

o Transaction SM30 allows the display and maintenance functions for this table/view.

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.

Comment
Only the last two options are offered for maintenance views and maintenance view variants.
'Display/maintenance not allowed' does not apply since maintenance views and maintenance view variants
serve exclusively to generate a user interface. This is rejected in the option 'Display/maintenance not
allowed'.

When the standard maintenance tools are used, the system checks the corresponding authorizations of the
user.

Вам также может понравиться