|
Archives of the TeradataForumMessage Posted: Mon, 06 Apr 2015 @ 16:46:15 GMT
Uh, no, if you do LOCKING ROW .. FOR ACCESS, you get a dirty read on a PI (or equivalent has collisions). The following section of the manual might help: Using LOCKING ROW Note that LOCKING ROW does not generally lock a single row, but rather all rows that hash to a specific value. It is a row hash lock, not a row lock. The LOCKING ROW modifier cannot be used to lock multiple row-hashes. If you specify LOCKING ROW FOR ACCESS with multiple row-hashes, the lock is converted to LOCKING TABLE FOR ACCESS, but a WRITE or EXCLUSIVE row-hash lock severity is not transferred to a table-level lock. If a LOCKING ROW FOR WRITE severity is not applicable, the default table-level lock severity is maintained. A single value in an IN clause is accepted as a valid row-hash lock specification. The use of LOCKING ROW prevents possible deadlocks occurring when two simultaneous primary index SELECTs are followed by an UPDATE, DELETE, or INSERT on the same row. iv
| ||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||
Copyright 2016 - All Rights Reserved | ||||||||||||||||||||||||||||||||||||||||||||||||
Last Modified: 15 Jun 2023 | ||||||||||||||||||||||||||||||||||||||||||||||||