Making Powerful ABAP Applications Using Dynamic Open SQL

Below is a snippet from one of hundreds of articles available to ERPtips subscribers.

If you would like a complimentary copy of the full article, please email
Mark.Downs@ERPtips.com
(include the title of the article in your email)

To subscribe to ERPtips, go to
www.ERPtips.com/Subscribe.asp.

ERPtips Journal is published by Klee Associates, Inc.

ERPtips University provides both public and onsite training for SAP clients.
For more about ERPtips University, including the current schedule, click here:
www.ERPtips.com/WorkshopSchedule.asp

Making Powerful ABAP Applications Using Dynamic Open SQL

How often do you find that your department is calling in a consultant in order to make business
process changes to a custom-built SAP application? We know it happens frequently, and it adds
up quickly. But before you shrug and say, “it`s unavoidable,” you need to read Rehan Zaidi`s latest articl

Click here to read this Snippet

 SAPtips4On ABAP/J2EE
Making Powerful ABAP Applications
Page 
April / May 2007 Volume V Issue 2
Using Dynamic Open SQL –
A Guide for SAP® Developers and Consultants
Editor’s Note: How often do you
find that your department is call-
ing in a consultant in order to make
business process changes to a cus-
tom-built SAP application? We know
it happens frequently, and it adds up
quickly. But before you shrug and
say, “it’s unavoidable,” you need to
read Rehan Zaidi’s latest article on
Dynamic Open SQL. Rehan presents
a compelling case for taking some
extra steps in the initial develop-
ment of your applications that will
save you time and money down the
road when business needs dictate IT
changes.
Introduction
SAP customers hire consultants in
order to accommodate business pro-
cess changes in their custom-built
applications. However, if certain
measures are taken at the time of
initial development, this extra cost
incurred and (any associated time
waste) may be avoided. One of the
ways that SAP lets you achieve this
is with the application of Dynamic
SAPtipsJournal
Open SQL. Due to the numerous
advantages that Dynamic Open SQL
provides to customers, learning the
basics of this technique is essential
for developers and consultants.
The goal of this article is to provide
a detailed description of Dynamic
Open SQL and the benefits it pro-
vides. These are some of the ques-
tions that this article will address.
• What is Dynamic Open SQL and
why is it necessary?
• What are some of the dynamic pro-
gramming options available within
the SQL terrain?
• How can we incorporate these
options in our applications?
There are many
situations in which
certain parts of a
SQL statement may
not be determined
at the time of
program writing.
We’ll also discuss the clauses or
parts of SQL statements that may
be specified dynamically, as well as
highlight the importance of addition-
al code that should be used in con-
junction with Dynamic Open SQL.
Finally, I will use an easy-for-all
company scenario to illustrate how
this works, with, of course, any tips
learned from my experience.
This article is primarily intended
for ABAP developers, but SAP users
who regularly work with developers
to accommodate relevant flexibility
features in their programs may also
SAPtips.com
By Rehan Zaidi, Siemens Pakistan
find it useful. I will assume that the
reader is familiar with ABAP and
SQL statements .For more informa-
tion, refer to the SAP documentation
on http://help.sap.com. The Dynamic
Open SQL techniques described
in this article can be used in SAP
Release 4.6 and onwards.
Dynamic Open SQL –
An Overview
Dynamic Open SQL is an exten-
sion of Open SQL that allows you
to write generic database access/
modification code. This is done by
specifying certain parts (clauses) of
the SQL statements in the form of
dynamic elements or tokens. The
dynamic portion of the statement is
denoted by ABAP variables specified
in parenthesis.
There are many situations in which
certain parts (or parameters) of a
SQL statement may not be deter-
mined at the time of program writ-
ing. These may include the names of
the database tables, their fields, or
the logical condition upon which the
data is to be fetched. In such cases,
the known parameters are written
statically, whereas the unknown por-
tion is specified using suitable ABAP
variables. At the time of program
execution, the SAP system carries out
the parsing of the dynamic portion
of the SQL statement and combines
it with the static portion in order to
execute the entire SQL statement.
As compared to statements speci-
fied statically, we need to write extra
coding prior to the SQL statements
whose components are to be deter-
mined at runtime. This coding
SAPtips © 2007 Klee Associates, Inc.
 SAPtips4On ABAP/J2EE
Page 
April / May 2007 Volume V Issue 2
a) first creates the additional ABAP
variables to be used in the SQL
statement,
b) then, creates the Dynamic Open
SQL code construct,
c) and then stores this code in the
defined ABAP variables.
The art of Dynamic Open SQL
programming lies in combining these
SQL statements with some elegant
ABAP programming logic in order to
write powerful generic code. Dynam-
ic Open SQL provides a number of
advantages to SAP developers and
consultants:
• The code is more meaningful and
compact.
• No additional resources are used
for generating the source code.
• All appropriate syntax checks are
performed, and the program may
be debugged very easily.
Since SAP Release 4.6, the ABAP
language provides a stable set of
features pertinent to Dynamic Open
SQL. In the SAP Web Application
Server 6.10, the Dynamic Open SQL
capabilities of ABAP were further
improved. Some of the statements
(and their clauses) that may be
specified dynamically are shown in
SAPtipsJournal
Figure 1.
Statements Components (clauses )
SELECT S ELECT, FROM, WHERE,
GROUP BY and HAVING
UPDATE WHERE, FROM
INSERT WHERE, FROM
DELETE WHERE, FROM
Figure 1: Statements and Components That May Be
Dynamically Specified
To better understand the working
of Dynamic Open SQL constructs,
let’s consider a simple example of a
Dynamic Open SQL statement. For
determining the number of rows of a
table, the following static statement
may be used:
SELECT COUNT(*) FROM SPFLI INTO MYNUM.
The above statement specifically
counts the total records in the data-
base table SPFLI. However, if you
need to write a program for any data-
base table that the user specifies, the
following Dynamic Open SQL state-
ments will be required:
DATA: MYTABLE(20).
SELECT COUNT(*) FROM (MYTABLE) INTO
MYNUM.
Note: The variable that refers to the
dynamic part of the SQL statement is
specified in parenthesis, for example
(MYTABLE).
At runtime, the variable MYTABLE
is populated with the name of the
table that you are interested in. The
SELECT statement is then used to
read the number of rows in the table
and store the value in the MYNUM
variable.
Dynamically Specifying
Parts of the SELECT state-
ment
As already mentioned, a number
of clauses of the SELECT statement
may be specified dynamically. Let’s
look at them individually.
1) Dynamic FROM and INTO
Clause
The FROM and INTO clauses let
you access data records from data-
base tables and store them into suit-
able data variables. The main dif-
ficulty with Dynamic Open SQL, in
this case, lies in declaring an area in
which the data is to be stored. A pow-
erful method for creating a dynamic
working area is to use the CREATE
DATA statement.
This requires a few steps:
SAPtips.com
• In the first step a variable, MYREF,
is defined as:
DATA: MYREF TYPE REF TO DATA.
This is used for storing the refer-
ence to the data object.
• Next, a working area corresponding
to the dynamic table name stored
in MYTABLE is created:
CREATE DATA MYREF TYPE (MYTABLE).
This statement lets you make
MYREF refer to the work area.
• You’ll then define a field symbol
that should point to your work
area. This assignment is made via
an ASSIGN statement:
FIELD-SYMBOLS : <ONERECORD> TYPE
ANY.
ASSIGN MYREF->* TO <ONERECORD> .
• The SELECT statement is finally
used to read data row by row from
the table in question, with the help
of the work area pointed by field
symbol ONERECORD:
SELECT * FROM (MYTABLE) UP TO 100 ROWS
INTO <ONERECORD>.
……
.......
ENDSELECT.
From Release 6.10, you may also
declare entire tables based on run-
time data (i.e., an internal table hav-
ing a line type specified at runtime).
The steps required in this case are as
follows:
• A field symbol and a data refer-
ence, along with the table name,
are declared as shown below:
DATA : MYTAB TYPE TABNAME.
DATA : MYREF TYPE REF TO DATA.
FIELD-SYMBOLS : <MYTABLE> TYPE ANY
TABLE.
SAPtips © 2007 Klee Associates, Inc.