Effects of Isolation Levels
You cannot set the transaction isolation level in a database that does not have logging. Every retrieval in an unlogged database occurs as a Read Uncommitted.
The data that is obtained during retrieval of BYTE or TEXT data can vary, depending on the transaction isolation levels. Under Read Uncommitted or Read Committed isolation levels, a process is permitted to read a BYTE or TEXT column that is either deleted (if the delete is not yet committed) or in the process of being deleted. Under these isolation levels, an application can read a deleted BYTE or TEXT column when certain conditions exist. For information about these conditions, see the HCL OneDB™ Administrator's Guide.
In ,
if you use a scroll cursor in a transaction, you can force consistency
between your temporary table and the database table either by setting
the isolation level to Serializable or by locking the entire table.
A scroll cursor with hold, however, cannot guarantee the same consistency
between the two tables. Table-level locks set by Serializable are
released when the transaction is completed, but the scroll cursor
with hold remains open beyond the end of the transaction. You can
modify released rows as soon as the transaction ends, so the retrieved
data in the temporary table might be inconsistent with the actual
data.
Warning: Do not use nonlogging
tables within a transaction. If you need to use a nonlogging table
within a transaction, either set the isolation level to Repeatable
Read or lock the table in exclusive mode to prevent concurrency problems.