System Not Reflecting Changed/Modified Data

[will]

Hi There

I hope this is an easy one ..
When 2 clients connect to the DB and client 1 modifies an existing record the changes does not reflect on client 2 machine untill client 2 disconnects and reconnects to the DB.

I tried using an after-image-writer AIW but my version of Progress does not allow this as it can only be used with the "Enterprise Edition".

Does any one know of any DB startup parameters or client connection parameters that will reflect modified data immedietly on all clients currently connected to the specified DB ??

Thanks

 

[Norman Biggar]

Are you using the -rereadnolock parameter? If not, that might fix your problem. SEE BELOW


This startup parameter changes the behavior of NO-LOCK record retrieval.

When a PROGRESS client (4gl, AppServer, web-agent) makes a request to find a record with NO-LOCK, it will not always get the newest copy of the record. If the record is already being used NO-LOCK by another 4GL buffer then the old copy usually remains in memory rather than replacing it with a new copy. This behavior is not always desirable.

The basic mechanism that accounts for this behavior works like this. PROGRESS first fetches the record from the database. PROGRESS then takes the ROWID of the record and compares it to the ROWIDs of records that are already in memory, in use by other 4gl buffers.

If the ROWID matches one of the records in memory, PROGRESS usually discards the new one, instead of the older record. This does not happen when the new record contains more information than the old one, for example, when the new record has more fields because it was based on a different field list.

The -rereadnolock startup parameter causes PROGRESS to discard the older record and replace it with the latest version. The following rules describe how this startup parameter interacts with related PROGRESS features:

-rereadnolock:


* affects the behavior of NO-LOCK record retrieval by FOR EACH or PRESELECT EACH.

* affects the behavior of NO-LOCK FINDs except for retrieval by RECID or ROWID as described below.

* does not affect the behavior of NO-LOCK FINDs based on retrieval by RECID or ROWID. PROGRESS immediately looks in memory for the record, and does not read a new record if there is a copy in memory.

* affects the behavior of retrieval on a NO-LOCK QUERY except for CACHEing and network PREFETCHing as described below.

* does not affect the behavior of a query cache. The DEFINE QUERY statement has an optional CACHE n phrase. Browsing a query uses a default cache of 20 records. This startup parameter does not cause the record to be re-read if it is in the cache.

* does not affect the behavior of a network PREFETCH cache. By default, OPEN QUERY across a network uses a prefetch buffer that may contain multiple records read-ahead by the server. This startup parameter does not cause the record to be re-read if it is in the cache. OPEN QUERY has a NO-PREFETCH option that eliminates this network cache.
​

 

[will]

Thanks again Norman

Works like a charm !!!

I will have a look at how it affects the performance of the system as I assume it may slow things down a bit....

 

[Norman Biggar]

Progress insists that it does not affect performance.
From Progress Knowledgebase P43776:

The -rereadnolock parameter does not affect the performance. It comes into the picture only after both (old and new) record's copies are in client's memory by indicating what copy should be used and what copy should be ignored.

 

[BONO]

For information,

-rereadnolock contains incompatibilty with field option on for each syntax :
One program x acces tableA field: 1 2 3 on session A
with a for each tableA fields(1, 2, 3)

Second program Y access tableA field 1 on session A
with a for each tableA FIELDS(1)

If u return on program X and make an action like click on a button, if on the button trigger u use fieds 2 or 3 , u will have a message that field 2 not in query.

This bug is efficient in 9.1D08 since V8, perhaps before. I didn't test in in V10