I rarely use READO, but I am revisiting the locking facilities in our Application.

I note that the documentation says READO 'can' be faster due to caching, and that the most recent record cannot be guaranteed.

Can anybody shed any light as to what sort of performance gain could be expected from a READO instead of a READ, ie when no updates are expected, such as reporting and screen population etc.

Also, if the most current record is not guaranteed, then is there any point in READO except in the most basic of facilities.

Thanks.

Colin,

In general, I would use READO (which stands for Read Only) if I do not have the record locked, and READ if I do have the record locked.

In the past, this made SELECT/READNEXT loops much faster, because during the READNEXT which extracted the ids, the record itself got cached locally.  By using a READO after the READNEXT, the cached record could be returned.  However, if you were also locking records in such a loop, then it would be important to use READ to reread the record on disk to ensure that the record is the most current version after the LOCK was obtained.

This caching is still performed when using the NPP in client mode.  However, with the current batch of server based network products READ's and READO's are handled the same.

I would still continue to code READNEXT loops this way, because there could easily be optimization performed in the future by the system.

Pat

View this thread on the forum...