Since your web browser does not support JavaScript,
here is a non-JavaScript version of the image slideshow:

Always
specify your conditions in the Where-clause instead of checking them yourself
with check statements. The database system can then use an index (if possible)
and the network load is considerably less.

For
all frequently used Select statements, try to use an index. You always use an
index if you specify (a generic part of) the index fields concatenated with
logical Ands in the Select statement's Where clause. Note that complex Where
clauses are poison for the statement optimizer in any database system.

If
there exists at least one row of a database table or view with a certain condition,
use the Select Single statement instead of a Select-Endselect-loop. Select Single
requires one communication with the database system, whereas Select-Endselect
needs two.

It
is always faster to use the Into Table version of a Select statement than to
use Append statements.

To
read data from several logically connected tables use a join instead of nested
Select statements. Network load is considerably less.

If
you want to find the maximum, minimum, sum and average value or the count of
a database column, use a select list with aggregate functions instead of computing
the aggregates yourself. Network load is considerably less.

If
you process your data only once, use a Select-Endselect-loop instead of collecting
data in an internal table with Select Into Table. Internal table handling takes
up much more space.

Use
a select list or a view instead of Select * , if you are only interested in
specific columns of the table. Network load is considerably less.

For
all frequently used, read-only tables, try to use SAP buffering. Network load
is considerably less.

Whenever
possible, use array operations instead of single-row operations to modify your
database tables. Frequent communication between the application program and
database system produces considerable overhead.

Use
the CONCATENATE statement instead of programming a string concatenation of your
own.

If
you want to delete the leading spaces in a string, use the ABAP/4 statement
SHIFT...LEFT DELETING LEADING... .Other constructions (with CN and SHIFT...BY
SY-FDPOS PLACES, with CONDENSE if possible, with CN and ASSIGN CLA+SY-FDPOS(LEN)
...) are not as fast. In any case, avoid using SHIFT inside a WHILE-loop!

Use
the SPLIT statement instead of programming a string split yourself.

Use
the strlen( ) function to restrict the DO loop to the relevant part of the field,
e.g. when determinating a check-sum.

Use
"CLEAR f WITH val" whenever you want to initialize a field with a value different
from the field's type-specific initial value.

Try
to keep the table ordered and use binary search or used a table of type SORTED
TABLE. If TAB has n entries, linear search runs in O( n ) time, whereas binary
search takes only O( log2( n ) ).

A
dynamic key access is slower than a static one, since the key specification
must be evaluated at runtime. However, for large tables the costs are dominated
by number of comparison needed to locate the entry.

If
you need to access an internal table with different keys repeatedly, keep your
own secondary indices.With a secondary index, you can replace a linear search
with a binary search plus an index access.

LOOP
... WHERE is faster than LOOP/CHECK because LOOP ... WHERE evaluates the specified
condition internally. As with any logical expressions, the performance is better
if the operands of a comparison share a common type. The performance can be
further enhanced if LOOP ... WHERE is combined with FROM i1 and/or TO i2, if
possible.

Always use Pretty Printer and Extended Program Check before releasing the code.
Do not leave unused code in the program. Comment the code thoroughly. Align the comments and the Code. Follow the SAP Standards and SAP Best Practices guidelines. It’s a good practice to take a dump of the code on your local drive.

Information we gathers through aggregated tracking information derived mainly by tallying page views throughout our sites. This information allows us to better tailor our content to readers’ needs and to help our advertisers and sponsors better understand the demographics of our audience. Under no circumstances we divulge any information about an individual user to a third party.

Cookie Tracking: We may place a text file called a “cookie” in the browser files of your computer. The cookie itself does not contain Personal Information although it will enable us to relate your use of this site to information that you have specifically and knowingly provided. But the only personal information a cookie can contain is information you supply yourself. A cookie can’t read data off your hard disk or read cookie files created by other sites. We may use cookies to track user traffic patterns (as described above).

We allow third-party advertising companies (like Google Adsense) to serve ads when you visit our Web site. If you would like more information about this practice and to know your choices about not having this information used by these companies, Visit This.http://www.google.com/privacy_ads.html
* Google, as a third party vendor, uses cookies to serve ads on your site.
* Google's use of the DART cookie enables it to serve ads to your users based on their visit to your sites and other sites on the Internet.
* Users may opt out of the use of the DART cookie by visiting the Google
ad and content network privacy policy.