Kbase 16264: Example - converting PREPROCESSOR variable w/ 4gl string ops
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
10/05/1998 |
|
Example - converting PREPROCESSOR variable w/ 4gl string ops
The code example below demonstrates how to convert a
preprocessor variable in the format "dbname.tablename.fieldname"
to the format "dbname.tablename", using the result to
access an actual database table.
There are no preprocessor statements in PROGRESS that allow
this conversion to take place at the preprocessor layer of the
compiler. As a result, the conversion requires the use of
4gl string operations. This in turn means that the resulting
string cannot then be used as a preprocessor again, in the
manner that the original was.
Preprocessing and compiling can be seen as consisting
of two steps:
(1) PREPROCESS: replace all "&VARIABLE"s with their
defined strings, if any.
(2) COMPILE: execute 4gl statements, including those
which make use of preprocessor variables.
In this example, the substituted string from step (1)
is being converted to another string in step (2). The
problem that arises is that the final product of step (2)
cannot then be substituted per the rules of step (1);
it is not possible to go backward in the process.
This results in two critical limitations to the approach.
The first limitation is that once the preprocessor has
been converted using string operations, it is necessary to call
another .p and pass the new string as an argument. It is *not*
possible to use the string to access a database table in the
same .p where the conversion is taking place. This is due to
the inability of PROGRESS to do dynamic queries. (See Kbase
15408, "Dynamic query or FOR EACH with variable fields or
tables", for more information on dynamic queries in PROGRESS.)
The second critical limitation is that the called .p in this
example cannot be precompiled. Again, this is due to the fact
that PROGRESS cannot work with dynamic queries. All frame
layouts must be resolved at compile time. Since the conversion
takes place in the 4gl, it is necessary to follow the 4gl rules
for dynamic queries. These rules include the necessity to
call an uncompiled procedure and pass in the tablename as an argument.
For the sake of clarity the example is first blocked out using
defined variables. There then follows a condensed version
of the same logic.
/* The preprocessor variable used is called &DBPR. It
is defined in this example as "sports.customer.name".
The goal is to convert this to "sports.customer" then
use the string "sports.customer" to access an actual
customer record in the database Sports. */
&SCOPED-DEFINE dbpr sports.customer.name
/* Define holder variable. */
DEF VAR x AS CHAR FORMAT "x(20)".
x = SUBSTRING("{&dbpr}", 1, R-INDEX("{&dbpr}",".") - 1).
/* The variable x now contains the preprocessor in the
format "dbname.tablename". Pass this as an argument
to an external, uncompiled procedure called find.p */
RUN find.p x.
/*********************************************************/
/* The find.p procedure is shown below. */
/* FIND.P */ /* CANNOT BE A .r FILE !!! */
FIND FIRST {1} NO-LOCK.
DISPLAY {1}.
To prevent runtime errors when the preprocessor variable does
not contain all three components (dbname, tablename, and fieldname),
do a check for two instances of ".":
IF INDEX("{&dbpr}", ".") <> R-INDEX("{&dbpr}", ".") THEN DO:
SEE ALSO:
---------
Kbase 15408, "Dynamic query or FOR EACH with variable
fields or tables"
Progress Software Technical Support Note # 16264