SAS/ACCESS 9.2 for Relational Databases: Reference, Fourth Edition

The LIBNAME Statement for Relational Databases 4 OR_UPD_NOWHERE= LIBNAME Option 1633 any SELECT SQL statement that was submitted by using the SELECT * FROMCONNECTION as a pass-through statement3 any statement other than the SELECT SQL statement that you submitted byusing the EXECUTE statement as a pass-through statementOR_UPD_NOWHERE= LIBNAME OptionSpecifies whether SAS uses an extra WHERE clause when updating rows with no locking.Alias: ORACLE_73_OR_ABOVE=Default value: YESValid in: SAS/ACCESS LIBNAME statementDBMS support: OracleSyntaxOR_UPD_NOWHERE=YES | NOSyntax DescriptionYESspecifies that SAS does not use an additional WHERE clause to determine whethereach row has changed since it was read. Instead, SAS uses the SERIALIZABLEisolation level (available with Oracle 7.3 and above) for update locking. If a rowchanges after the serializable transaction starts, the update on that row fails.NOspecifies that SAS uses an additional WHERE clause to determine whether each rowhas changed since it was read. If a row has changed since being read, the update fails.DetailsUse this option when you are updating rows without locking(UPDATE_LOCK_TYPE=NOLOCK).By default (OR_UPD_NOWHERE=YES), updates are performed in serializabletransactions. It lets you avoid extra WHERE clause processing and potential WHEREclause floating point precision problems.Note: Due to the published Oracle bug 440366, an update on a row sometimes failseven if the row has not changed. Oracle offers the following solution: When creating atable, increase the number of INITRANS to at least 3 for the table. 4See AlsoTo apply this option to an individual data set or a view descriptor, see the“OR_UPD_NOWHERE= Data Set Option” on page 355.“Locking in the Oracle Interface” on page 728“UPDATE_LOCK_TYPE= LIBNAME Option” on page 196