Professional Documents
Culture Documents
Q. 1
Hi folks.
I would like to know the difference between Different types of buffering with respect to
accessed data, situations and performance criteria.
Regards Harsh.
Thread: Buffering Types?
This question is answered.
Q. 2
Hi folks.
I would like to know the difference between Different types of buffering with respect to
accessed data, situations and performance criteria.
Regards Harsh.
Re: Buffering Types?
Posted: Jun 30, 2008 3:33 PM
Reply
Harsh,
The buffering type defines whether and how the table should be buffered.
There are the following types of buffering:
single-record buffering
generic area buffering
full buffering
In generic area buffering, a number of key fields between 1 and no. of key fields-1 must
be specified.
Single-record buffering
With this kind of buffering, only the records of a table which are actually accessed are
For tables up to 30 KB in size. If a table is accessed frequently, but all accesses are read
accesses, this value can be exceeded.
For larger tables where large numbers of records are frequently accessed. However, if
the application program is able to formulate an extremely selective WHERE condition
using a database index, it may be advisable to dispense with full buffering.
For tables with frequent accesses to data not contained in the table. Since all records
are contained in the buffer, a quick decision can be made as to whether or not the table
contains a record for a specific key.
When considering whether a table should be fully buffered, you should take three
aspects into account: the size of the table, the number of read accesses, and the
number of write accesses. Tables best suited to full buffering are small, frequently read,
and rarely updated.
Database Logical Unit of Work (LUW)
The database changes that occur within a database LUW are not actually written to the
database until after the database commit. Until this happens, you can use a database
rollback to reverse the changes. In the R/3 System, database commits and rollbacks can
be triggered either implicitly or using explicit commands.
Implicit Database Commits in the R/3 System
A work process can only execute a single database LUW. The consequence of this is
that a work process must always end a database LUW when it finishes its work for a
user or an external call. Work processes trigger an implicit database commit in the
following situations:
When the called function module (RFC) in the other work process ends.
Control returns to the calling work process.
This statement starts a database commit, but also performs other tasks (refer to
the keyword documentation for COMMIT WORK).
Implicit Database Rollbacks in the R/3 System
The following cases lead to an implicit database rollback:
Termination message
Termination messages are generated using the ABAP statement MESSAGE with
the message type A or X. In certain cases (updates), they are also generated with
message types I, W, and E. These messages end the current application program.
Explicit Database Rollbacks in the R/3 System
You can trigger a database rollback explicitly using the ABAP statement
ROLLBACK WORK. This statement starts a database rollback, but also performs
other tasks (refer to the keyword documentation for ROLLBACK WORK).
From the above, we can draw up the following list of points at which database LUWs
begin and end.
A Database LUW Begins
Each time a dialog step starts (when the dialog step is sent to the work
process).
Each time a database commit occurs. This writes all of the changes to the
database.
Each time a database rollback occurs. This reverses all of the changes made
during the LUW.
Database LUWs and Database Locks
As well as the database changes made within it, a database LUW also consists of
database locks. The database system uses locks to ensure that two or more users
cannot change the same data simultaneously, since this could lead to inconsistent data
being written to the database. A database lock can only be active for the duration of a
database LUW. They are automatically released when the database LUW ends. In order
to program SAP LUWs, we need a lock mechanism within the R/3 System that allows us
to create locks with a longer lifetime (refer to
Data Class
Use
If you choose the data class correctly, your table is automatically assigned to the correct
area (table space or DB space) of the database when it is created. Each data class
corresponds to a physical area in which all the tables assigned to this data class are
stored.
There are the following data classes:
Customizing data that is defined when the system is installed and seldom
changed. An example is the table with country codes.
Two further data classes, USR and USR1, are provided for the customer. These are for
user developments. The tables assigned to these data classes are stored in a table
space for user developments. In the following figure you can see tables assigned to
different data classes. The figure presents the tables in the ABAP Dictionary and in the
database.
Scenario Introduction
There are two ways to implement polymorphism a concept of Object oriented
programming using ABAP Objects. I make an attempt to explain each one of them with a
elaborate sample ABAP Report in which I will try to implement most of the concepts
related to polymorphism.
I have used elements of Object oriented programming in a report, which is written
following structural programming methodology.
Requirement: We take an example of a company, which makes and sells electronic
goods that it manufactures and retails through its various stores. It takes bulk sales order
and determines the price of each item sold according to the customer type. The
customers are of 3 types to keep it simple
1) First time customers: New customers, which are ordering from the company for the
first time. There is no discount given by the company
2) Regular customers: Customers which order products from the company from time
to time
3) Valued customer: Customers which order large quantities and have a=had a long
purchase history with the company
P.S. : The below code snippet makes certain assumption for the sake of enhancing the
stress on concept of Polymorphism. Hence standards like Data validation are not
followed.
Explanation: Most of the ABAP report starts with Data declaration and generally all class
and interface definitions are defined at the start of report.
At the end of an include. There are some restrictions, for example, not at the
end of a method include.
At the end of a structure definition (before TYPES END OF, DATA END OF,
CONSTANTS END OF, and STATICS END OF).
Definition
The enhancement spots are used to manage explicit enhancement options.
Enhancement spots carry information about the positions at which enhancement options
were created. One enhancement spot can manage several enhancement options of a
Repository object. Conversely, several enhancement spots can be assigned to one
enhancement option.
Use
You create an explicit enhancement option when processing a Repository object with the
relevant tool by creating an enhancement spot element definition at a point where this is
possible. This enhancement option can then be called at different points using
enhancement spot element calls. The enhancement spot element definition and the