SQL/MX 2.x Installation and Management Guide (H06.10+, J06.03+)

Managing Database Applications
HP NonStop SQL/MX Installation and Management Guide—544536-007
11-2
Recovery for Read-Only Queries
resolved by the takeover of the backup CPU or the prompt restoration of the network
connection.
Any active transaction that does transaction work on a data volume incurs a unilateral
abort when the CPU for the primary DP2 process fails. This is fundamental to high
performance with audited tables and is true for Enscribe, NonStop SQL/MP, and
NonStop SQL/MX. The transaction abort is initiated by the backup DP2 process during
an unplanned takeover.
TMF might also initiate an abort for some transactions. Typical TMF-based applications
are designed to redrive failed transactions.
When a transaction is aborted, an indication is placed in the SQL/MX diagnostics area
with a SQLCODE of 8839. This SQLCODE might not be the first returned code. To
detect SQLCODE 8839, the application can examine the entries in the diagnostics
area using the GET DIAGNOSTICS SQL statement. For more information, see the
discussion on accessing and using the diagnostics area in the SQLMX Programming
Manual for C and COBOL.
The application can be designed to redrive a transaction that was aborted. To avoid a
loop, the redrive should not be attempted more than once. Note that when the TMF
transaction has been aborted by the system (SQLCODE 8839), the application can
end the transaction with either COMMIT WORK or ROLLBACK WORK. The result is
the same since the transaction is already aborted.
Some errors that might cause a TMF transaction abort might not be retryable, such as
errors caused by conditions that must be resolved with some corrective action by the
user or application. For example, depending on the application, it might not be useful to
retry a duplicate key error returned by an INSERT statement using ROWSETS. This
error causes a TMF transaction abort, but it is not retryable unless the existing record
with the duplicate key is deleted. The application error-handling logic can be written so
that these types of errors are not retried.
Table 11-1 identifies the SQLCODES that are most commonly not retryable unless
corrective action is taken by the application to correct the condition. For more
information about these error messages, see the SQL/MX Messages Manual.
Recovery for Read-Only Queries
If the application is processing a FETCH statement (with or without rowsets) for a
read-only cursor (no UPDATE/DELETE), and the primary DP2 process fails because of
a CPU failure, the application receives SQLDCODE 8550 with NSK_CODE 1061.
Table 11-1. SQLCODES and the Constraints That Prevent Retry Operations
SQLCODE Meaning
8101 The operation is prevented by a check constraint.
8102 The operation is prevented by a unique constraint.
8103 The operation is prevented by a referential integrity constraint.