Kbase 15850: Why does Report Builder require a separate database connection?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
15/10/2008 |
|
Status: Verified
GOAL:
Why does Report Builder require a separate database connection?
GOAL:
How does Report Builder connect to database?
GOAL:
What options are supported when connect report builder to database?
FIX:
The reason that Report Builder/Report Engine requires its own separate connection to the database (apart from the rest of Progress) is that it is a separate executable. All of the other Progress tools, ie. Results, UIB, etc, are procedures called from the main Progress executable. Report Builder is a separate product written in C language that Progress bought from another company. There is no way to make it a part of the Progress executable. Report Builder will always require a separate connection to the database.
Report Builder requires a multi-user database connection, either using shared-memory or using client/server network parameters -H, -S, -N.
With a single-user license there are three ways to go around this multi-user requirement.
One way is to use the database in multi-user mode with the server included with the single-user license.
Prior to Progress 8.2, the WIPC is available via the wproserv.exe executable.
This server is slower than a regular server but will allow the application to function correctly.
Beginning with Progress 8.2, single-user licenses can start a local database server via _mprosrv.exe, and connect either using shared memory or -N TCP (standard TCP/IP networking).
The second option is to write the 4GL application in such a way that the DISCONNECT statement does the work. This is tricky but it can be done.
The third option is to use the parameter -RO.
Keep in mind the following items,
a) DISCONNECT gets deferred if there is a transaction
open (the DISCONNECT statement appears to execute
correctly, but under the table, PROGRESS defers the
actual disconnection until the transaction finishes).
b) DISCONNECT gets deferred if there are any
active .p files (i.e. .p files still on the execution
stack) that refer to the database. Even though the
DISCONNECT appears to execute correctly, and even
though the CONNECTED built-in function returns FALSE,
under the table the PROGRESS executable hangs on to
the connection (and keeps the lock file in place)
until the last .p that refers to the database
has returned.
The combination of these restrictions means that in order for a 4GL application to successfully disconnect (with the lock file actually going away so that the Print Engine can get at the database), it has to be sure there are no transactions open and no .p files active that refer to the database.