(B)0[mtx-options =
qwqq> [4mBATCH_UPDATE[m qqqqqqqqqqq>qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqw>
mwqqqqqqqqqqqqqqqqqqwqwqqqqqq>qqqqqqwqwqqqqqqqqqqqqqqqqqqwqk x
tq> [4mREAD_ONLY[m qqu tq> [4mWAIT[m qqqqqu tqq> [4mCONCURRENCY[m qqu x x
mq> [4mREAD_WRITE[m qqj mq> [4mNOWAIT[m qqqj mqq> [4mCONSISTENCY[m qqj x x
lqqqqqqqqqqqqqqqqqqqqqqqqqqqq<qqqqqqqqqqqqqqqqqqqqqqqqqqqqqj x
mwqqqqqqqqqqqqqqqqq>qqqqqqqqqqqqqqqqqqqqqqqwqk x
mq> [4mEVALUATING[m qwq> evaluating-clause qqwqj x x
mqqqqqqqq , <qqqqqqqqqqqj x x
lqqqqqqqqqqqqqqqqqqqqqqqqq<qqqqqqqqqqqqqqqqqqj x
mwqqqqqqqqqqqqqqqqqqqqqqqqqqqqq>qqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqwj
mq> [4mRESERVING[m qwq> reserving-clause qwqwqqqqqqqqqqq>qqqqqqqqqqqwj
mqqqqqqqq , <qqqqqqqqqj tq> [4mWITH[m [4mAUTO_LOCKING[m qqu
mq> [4mWITH[m [4mNOAUTO_LOCKING[m j
1 – BATCH_UPDATE
Before you begin a batch-update transaction in your programs, you
should create a backup copy of the database.
You can reduce overhead in large, initial load operations by
using the BATCH_UPDATE option. To speed update operations,
Oracle Rdb does not write to the process' recovery-unit journal
(RUJ) file in the batch-update transaction. Therefore, you
cannot explicitly roll back a batch-update transaction with a
ROLLBACK statement. If Oracle Rdb attempts to perform an automatic
rollback due to any error (for example, a constraint condition is
violated) that you do not trap in your program, the transaction
fails and your database is permanently corrupted (because no
RUJ file exists). You must then re-create the database from
the backup copy you created prior to starting the batch-update
transaction. After you have corrected the error condition, you
can restart the program from the beginning.
For critical information on the hazards of batch-update
transactions, read the START TRANSACTION statement's section
on batch-update transactions in the RDO reference manual.
2 – READ_ONLY
If you start a read-only transaction, you can retrieve a snapshot
of the database at the moment the transaction started. Other
users can update records in the relation you are using, but your
transaction retrieves the records as they existed at the time
the transaction started. Any changes that other users make and
commit during the transaction are invisible to you. A read-only
transaction lets you read data without incurring the overhead
of record locking. You cannot modify, store, or erase records or
execute data definition statements in a read-only transaction.
3 – READ_WRITE
Signals that you want to use the locking mechanisms of Oracle Rdb
to get consistency in data retrieval and update. Use a read/write
transaction mode when you need to:
o Store, modify, or erase data
o Retrieve data that is guaranteed to be correct at the moment
of retrieval
o Use Oracle Rdb data definition statements
4 – WAIT_NOWAIT
Determines what your transaction does when it encounters a locked
record:
o If you specify WAIT, the transaction waits for others to
complete and then proceeds. WAIT is the default.
o If you specify NOWAIT, your transaction returns an error
message when it encounters a locked record.
5 – CONSISTENCY_CONCURRENCY
The CONSISTENCY and CONCURRENCY options control the extent to
which the database protects the consistency of your data.
The broadening of isolation level support in Oracle Rdb V4.2 changed
the way that Oracle Rdb treats RDO, RDBPRE, and RDML applications
that use CONCURRENCY transactions. With Oracle Rdb V4.1 and earlier
databases, these applications ignored the CONCURRENCY setting by
running their transactions at the default CONSISTENCY setting.
With Oracle Rdb V4.2 and later databases, the transactions are run
at the CONCURRENCY setting specified.
Because Oracle Rdb V4.2 expanded the CONCURRENCY setting in the
START_TRANSACTION statement of RDO, your DBA should check those
RDO, RDBPRE, and RDML applications that specify the CONCURRENCY
keyword in START_TRANSACTION statements to ensure that the
applications return expected results at the reduced consistency
level defined by the CONCURRENCY setting.
Your RDO, RDBPRE, and RDML applications that explicitly specify
CONCURRENCY in START_TRANSACTION statements will now operate in
Oracle Rdb V4.2 and later versions at the equivalent (SQL)
ISOLATION LEVEL READ COMMITTED (formerly called CONSISTENCY
LEVEL 2) when attached to either non-Oracle Rdb databases
or Oracle Rdb V4.2 and later databases. Those RDO, RDBPRE, and
RDML applications that do not explicitly specify a consistency
level or explicitly specify CONSISTENCY (default) will not change
transaction behavior.
In pre-Oracle Rdb Version 4.2 releases, Oracle Rdb ran application
transactions at the CONCURRENCY setting against non-Oracle Rdb
databases only and ignored the CONCURRENCY setting when
attached to Oracle Rdb databases. Instead of running these latter
applications at CONSISTENCY LEVEL 2 (CONCURRENCY), as you might
expect, Oracle Rdb ran them at the default CONSISTENCY LEVEL 3.
For Oracle Rdb Version 4.2 and later versions, however, RDO, RDBPRE,
and RDML applications that use the CONCURRENCY (CONSISTENCY
LEVEL 2) setting in transactions attached to Oracle Rdb Version
4.2 and later databases will no longer automatically revert
to CONSISTENCY LEVEL 3 as was true in Oracle Rdb Version 4.1
and earlier releases. Instead, they will run at the specified
CONCURRENCY (CONSISTENCY LEVEL 2) setting.
Refer to the "Differences in Relational Terminology" table in the
"Terminology" subtopic of the DECRDB topic in the DCL help file
for the relationship between SQL isolation level terminology and
its equivalent RDO, RDBPRE, and RDML terminology.
You can use the Oracle Rdb RDMS$DEBUG_FLAGS logical "T" option to
determine the consistency level at which your executable images
are running. The "T" option displays application transaction
characteristics and will display TPB$K_DEGREE2 for those
applications that use the CONCURRENCY option.
Because some 4GL's also use CONCURRENCY, you should contact
your 4GL vendor about possible changes in transaction behavior;
however, Rdb expects that in most cases the CONCURRENCY
option reflects how your DBA wants transactions to run and also
that your DBA understands that the reduced isolation level should
not be detrimental to applications.
In other database systems that you might want to access using
the remote feature of Oracle Rdb, this option specifies the degree
to which you want to control the consistency of the database. In
such systems, the CONCURRENCY option sacrifices some consistency
protection for improved performance with many users.
If you use the CONCURRENCY option, you may be able to transport
your programs to another system that takes advantage of that option
and achieve improved performance.
The default for Oracle Rdb is CONSISTENCY. When CONSISTENCY is
specified, Oracle Rdb always guarantees degree 3 consistency. Degree
3 consistency means that the database system guarantees that
data you have read will not be changed by another user before you
issue a COMMIT statement.
6 – evaluating-clause
(B)0[mevaluating-clause = qwqqqqqqqqqqqqqqqqwqq> constraint qq> [4mAT[m qqwq> [4mVERB_TIME[m qqqwq> mq> db-handle . qj mq> [4mCOMMIT_TIME[m qj
6.1 – Options
VERB_TIME When the data manipulation statement is issued
(default)
COMMIT_TIME When the COMMIT statement executes
db-handle A database handle (for multiple databases)
7 – reserving-clause
(B)0[mreserving-clause =
qqwqwqqqqqqqq>qqqqqqqqqqqqwqwq> relation-name qqwqwqqqk
x mq> db-handle qq> . qqj mq> view-name qqqqqqj x x
mqqqqqqqqqqqqqqqqqq , <qqqqqqqqqqqqqqqqqqqqqqqqqj x
x
lqqqqqqqqqqqqqqqqqqqqq<qqqqqqqqqqqqqqqqqqqqqqqqqqqqqj
mq> [4mFOR[m qqqwqqqqqqqq>qqqqqqqqqwqqqqwqq> [4mREAD[m qqqwqqq>
tqq> [4mEXCLUSIVE[m qqqqu mqq> [4mWRITE[m qqj
tqq> [4mPROTECTED[m qqqqu
mqq> [4mSHARED[m qqqqqqqj
7.1 – More
The list of relations to be locked during the transaction.
In general, include all the relations your transaction will
access. If you specify the AUTO LOCKING clause, constraints and
triggers defined on the reserved relations will be able to access
additional relations that do not appear in the list of reserved
relations.
Note that if you use the RESERVING clause without the AUTO
LOCKING clause, you can access only those relations that you
have explicitly reserved.
7.2 – Options
Option Access Constraints
SHARED Other users can work with the same relations
as you. Depending on the option they choose,
they can have read-only or read and write
access to the relations.
PROTECTED Other users can read the relations you are
using. They cannot have WRITE access.
EXCLUSIVE Other users cannot read records from the
relations included in your transaction. If
another user refers to the same relation in
a START_TRANSACTION statement, Oracle Rdb denies
access to that user.
READ You will only read data from the relations.
WRITE You will store, modify, or erase data in
the relations.
8 – AUTO_LOCKING
An optional clause that can be specified with the RESERVING
clause. When you specify the WITH AUTO_LOCKING clause, Oracle Rdb
automatically locks any relations referenced from constraints and
triggers defined on the reserved relations when the referenced
relations are accessed from the constraints or triggers. If one
of these referenced relations is also a reserved relation, the
explicitly specified lock mode must not conflict with the lock
mode required by the constraint or trigger that references the
relation.
The default is WITH AUTO_LOCKING. Specify the WITH NOAUTO_LOCKING
clause if you do not want to use the auto-locking option.