Kbase P106882: Statistics shown by VST's do not change within a 4GL program.
Autor |
  Progress Software Corporation - Progress |
Acesso |
  Público |
Publicação |
  10/16/2008 |
|
Status: Unverified
SYMPTOM(s):
Statistics shown by VST's do not change.
Statistics shown in the _UserIO table do not change.
Database records are accessed, nevertheless _UserIO._UserIO-DbAccess does not change.
One of the programs that call the program where the problem occurs, accesses table _UserIO too.
Client session is not using -rereadnolock
CAUSE:
Say that a.p accesses _UserIO, and that a.p calls b.p, which accesses _UserIO and where the problem shows.
When the record for _UserIO is read within a.p, a copy is stored in the client's local memory.
When the same record is re-read from within b.p, the client does not refresh the local image with the more recent image from the database; it keeps the older copy instead. This is what causes the observed behavior that the statistics do not change.
It has to be noted that this is the standard behavior when reading records NO-LOCK. VST tables indeed have no concept of record locking, and records in the VST's always behave like they were read NO-LOCK, even if you specify EXCLUSIVE-LOCK or SHARE-LOCK.
FIX:
There are two possible solutions:
1) Start the client session with -rereadnolock. While the easiest solution, -rereadnolock has implications that might break your application. Please see Solution 19063 for further details on the effects of using -rereadnolock.
2) Change the program(s) reading _UserIO so that the _UserIO record is RELEASE'd as soon as it's no longer needed, and at any rate before any subprogram or internal procedure is invoked. For example:
FIND _MyConnection.
FIND _UserIO WHERE _UserIO._UserIO-Usr = _MyConnection._MyConn-Userid.
ASSIGN myVariable = _UserIO._UserIO-DbAccess.
RELEASE _UserIO.
RUN b.p.