FWD » Core Development » Database

I found that a FIND statement of the following form is converted without a LockType.NONE lock type:

FIND FIRST table NO-LOCK WHERE ...

The actual statement I encountered was significantly more complicated than this, but I'm assuming the conversion omission can be replicated in a test case of this simplicity. If not, also try variations of:

FIND FIRST table NO-LOCK USE-INDEX index WHERE ... NO-WAIT NO-ERROR

The Progress documentation syntax diagram for FIND indicates that the lock specifier comes after the WHERE clause, but I'm guessing they honor this deviation.

Please determine whether Progress honors the NO-LOCK (also SHARE-LOCK, EXCLUSIVE-LOCK) option when specified out of order like this (not just at compile time, but at runtime as well).

To do the runtime test, you will need to start a database in multi-user mode (using the proserve program) and log into two sessions, where you will use the mpro (multi-user) client instead of the pro (single-user) client. In one session, lock a record with EXCLUSIVE-LOCK and pause while the record is locked. In the other session, try to access the locked record using a FIND statement with a misplaced lock specifier. Note that the default lock type for a FIND is SHARE-LOCK, so you should see SHARE-LOCK behavior if the misplaced NO-LOCK is not honored.

If you determine that Progress honors the misplaced option, we can discuss the best approach to fix the P2J conversion to match this behavior.

Was this in our code?

Paul Eames wrote:

Was this in our code?

Not that I'm aware of.