Kbase 17997: How to run the same code against databases with same schema
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
04/06/1998 |
|
How to run the same code against databases with same schema
This document explains how you can run the same procedure against
two databases which have the same schema but different data. (The
information can then be extended to cover situations with many more
than two databases, but for the purposes of this kbase we will
assume only two.)
The example given below assumes that you want to connect to one
database at a time, running the same procedure against each
individually.
One basic requirement is that the two databases be identical in
terms of schema and CRC. This example will not work if the databases
differ IN ANY WAY, even if the procedure to be run against them is
not saved as r-code.
A second basic requirement is that logical database names be used
when compiling and connecting, rather than physical names.
STEP 1: Create the two identical databases. For this example, the
physical names of the databases will be "firstdb" and "seconddb".
STEP 2: Whenever connecting to either "firstdb" or "seconddb" at
runtime *or* during development, include a logical name that is
identical for each. For this example, the logical name will be
"maindb".
STEP 3: Load different data into the two databases so that when it
is displayed you will be able to verify that you are indeed
seeing the data from the proper database.
STEP 4: Write a brief program to display the data. For example:
FOR EACH table1:
DISPLAY field1 field2 WITH SIDE-LABELS.
END.
Save this program as "display.p".
STEP 5: Compile and save "display.p" so that "display.r" results.
(This is where it is critical for you to have used the logical
name when connecting to the database to create "display.p".)
STEP 6: Write a main program that handles connecting and
disconnecting to the two databases, as well as running the
display program. For example:
CONNECT firstdb -1 -ld maindb.
RUN display.r.
DISCONNECT maindb.
CONNECT seconddb -1 -ld maindb.
RUN display.r.
DISCONNECT maindb.
IMPORTANT NOTE: The connection and disconnection from the
target databases takes place in the main program, while the
actual processing that uses the databases takes place in the
called program. You will be unable to include the code from
display.p in the same procedure where you do your connecting
and disconnecting. This is a characteristic of the PROGRESS
architecture.
DIAGNOSING COMMON ERRORS:
ERROR 1896 - If your database schema and CRC do not match, upon
trying to run display.p the second time you will see error 1896:
** CRC for table1 does not match CRC in display.p. Try
recompiling. (1896)
Why? Because even after PROGRESS has run display.p the first
time, the procedure remains in memory as compiled code.
This is the case even if r-code has not been created by the
programmer.
Even when p-code is compiled at runtime, an r-code "image"
is retained in memory after the procedure has completed
execution. When PROGRESS is asked to run the procedure the second
time, it recognizes that it still has this image stored in
memory and merely runs the image again. So, unless the logical
database names are the same for both target dbs, and unless
their CRC's match, error 1896 will result.
ERROR 1006 - If you fail to use the logical database names
properly, then when you try to run display.p the second time
you may get error 1006 in one of a few possible ways:
display.p Database firstdb is not connected. (1006)
(or)
display.p Database maindb is not connected. (1006)
This error also ties back to the way PROGRESS saves compiled
code in memory, even after the procedure has completed
execution. In this case, PROGRESS notices the mismatched
database names when display.p is run the second time. By using
the logical database names properly, you will be able to force
PROGRESS into seeing an identical name for the two databases
and eliminate error 1006.
ERROR 725 - If you attempt to incorporate the code used in
the display.p program into the same procedure where you do
your connects and disconnects, error 725 may result:
Unknown or ambiguous table table1. (725)
Again, you cannot process against a database within the same
procedure where you are connecting to that database. It is
recommended that you connect and disconnect from a top-level
procedure, then call the processing programs as subprocedures
of the main one -- as is shown in the example above.
IF THE PROCEDURE APPEARS TO IGNORE THE SECOND DATABASE CONNECTION
AND DATA FROM THE FIRST IS SHOWN BOTH TIMES - This is
likely because you started out already connected to one of
the databases, and/or placed the display.p code within the same
procedure as your db connects and disconnects. For best
debugging, start out with no databases connected. For proper
programming, connect and disconnect from a top-level program
and call the processing programs as subprocedures of the
main one -- as shown in the example above.
OTHER ERRORS - Other errors such as "ambiguous field" (72) or
(1762), "ambiguous table" (545), or "filename already
exists" (132) might result if you are implementing this type
of design incorrectly, depending on where you are going wrong.
ADDITIONAL REFERENCE:
See also Kbase 15842 "Error 1006 and compiling code on the fly
with multiple db".