If I Update a record without using an ET and then run a program to read that that same reord, the result I get is the “Updated” values in that same record - even though no ET was issued. The Natural session was not shut down so no ET was issued at close.
How do I prevent this from happening?
I assume the “Updated” record is held in a buffer and then retrieved at the next read. I want the program to read the database and not the buffer.
The updated record is held in Adabas’ Bufferpool, and there’s absolutely no way around retrieving that record and just that record.
To prevent “dirty reads” ensure that no updated record stays uncommitted for an extended period of time.
Please correct me if I’m wrong. IIRC, I’ve learned the following at the ADABAS-Training:
During update the changed values are written into the database itself (i.e. ASSO/DATA). During BACKOUT TRANSACTION the reagarding record is set to its old values. An END TRANSACTION only relaeses the record from hold.
This is why a BACKOUT TRANSACTION (two logical writes) takes more time than an END TRANSACTION (only one logical write).
That means: Garry’s Programs does read the database.
No, an update writes to the affected ASSO / DATA blocks in the bufferpool, only a bufferflush actually updates the database 
OK, I mixed up the technical and logical view. From a programmer’s point of view, an update followed by a BACKOUT changes the content of the database for a while.
I guess we then need to know the mechanism that will trigger a buffer flush. It seems to be different on a Windows server than on a mainframe - but I will test this on a mainframe just out of curiosity.
Thanks for your advice.
No data will be updated on disc without an ET, so the bufferflush-frequency (which can be influenced with the WRITE_LIMIT parm to adanuc, btw.) doesn’t change the picture at all.
It doesn’t matter if the data is written to disk already or not. If you update a record, any read of that record will read the updated version since Adabas will pull it from the buffer.
Adabas does not differentiate between committed updates and uncommitted updates.
If your application cannot tolerate “dirty reads”, then change it to do read-with-hold - it will not get the record until it is released by the application that is updating it. Ensure that your transaction timer values are set to something reasonable (typically around 15 minutes). Or set WH=OFF and use the ON ERROR RETRY (if desired) to retry getting the held record.