DB2 SQL Errors Codes and Error Messages and Warnings from Error -567 to -573
Error: DB2 SQL Error: SQLCODE=-567, SQLSTATE=42501, SQLERRMC=TBSPACEID=, TABLEID=, COLNO=, DRIVER=
bind-type AUTHORIZATION ERROR
USING auth-id AUTHORITY PACKAGE
= package-name PRIVILEGE = privilege
Explanation: The authorization ID given does not
have the privilege indicated, and cannot invoke the
indicated subcommand against the indicated package.
Type of bind subcommand (BIND | REBIND
auth-id Authorization ID of the package owner.
Name of the package
Name of the privilege not held:
v BINDADD—The authority to create a new
package using BIND with the ADD option.
v BIND—The authority to BIND (REPLACE)
or REBIND a package.
v COPY—The authority to COPY from the
v CREATE IN—The authority to create a
package in the indicated collection.
If you are using a trusted context, the token auth-id
might return a role instead of an authorization ID. A
role is returned if a role was in effect and the
authorization checking is performed against the role,
rather than the authorization ID of the session, when
the condition was encountered. Otherwise an
authorization ID is returned. A role is returned in the
following format as a single token:
v ROLE: role-name
System action: The indicated package is not bound,
rebound, or freed.
System programmer response: The indicated privilege
must be granted to the authorization ID that will
become the package owner.
Error: DB2 SQL Error: SQLCODE=-571, SQLSTATE=25000, SQLERRMC=TBSPACEID=, TABLEID=, COLNO=, DRIVER=
THE STATEMENT WOULD RESULT IN
A MULTIPLE SITE UPDATE
Explanation: This SQLCODE is issued in the
v When an application program operating in an IMS or
CICS environment attempts to modify data at a
remote location where multi-site update capabilities
are not supported.
v When an application program has explicit SQL
statements within a commit scope that would result
in updates at multiple sites where one of the sites at
which data is being updated does not support
This SQLCODE can be issued when an application
program explicitly modifies data at a single location
within a commit scope. This can occur in the following
v A package or plan associated with the application
program was invalidated.
v A package or plan was bound at one release of DB2
and fallback occurs to a prior release.
In the situations described above, an implicit autobind
is done on behalf of the user. An autobind results in the
DB2 catalog being updated. The conditions that must
exist for this SQLCODE to be issued when an autobind
v One site where data has been modified does not
support multi-site update.
v The autobind occurs at a separate and distinct site
from where an application program explicitly
v At the time of the autobind, locks are being held to
process an SQL statement within the application
System action: The statement cannot be executed.
v Ensure that all requests for modifications to the data
are confined to a single location within any given
commit scope for any application that references a
location that does not support multi-site update.
v For programs operating in an IMS or CICS
environment where the remote database systems do
not support multi-site update, all SQL statements
must be read-only access.
v If an autobind is causing this SQLCODE to be
issued, REBIND the plan or package.
Error: DB2 SQL Error: SQLCODE=-573, SQLSTATE=42890, SQLERRMC=TBSPACEID=, TABLEID=, COLNO=, DRIVER=
TABLE table-name DOES NOT HAVE A
UNIQUE KEY WITH THE SPECIFIED
Explanation: A referential constraint cannot be defined
with the specified table as the parent because a unique
index with the specified column names does not exist
for the identified parent table.
System action: The statement cannot be processed.
Programmer response: Create a unique index with the
specified columns for the parent table.
Above are list of DB2 SQL Errors and Warnings from Error — to — received while performing certain operation against DB2 Database or related products.
SQLCODE – Regardless of whether the application program provides an SQLCA or a stand-alone variable, SQLCODE is set by DB2 after each SQL statement is
executed. DB2 conforms to the ISO/ANSI SQL standard as follows:
If SQLCODE = 0, execution was successful.
If SQLCODE > 0, execution was successful with a warning.
If SQLCODE < 0, execution was not successful.
SQLCODE = 100, “no data” was found. For example, a FETCH statement returned no data because the cursor was positioned after the last row of the result table.
SQLSTATE – SQLSTATE is also set by DB2 after the execution of each SQL statement. Thus, application programs can check the execution of SQL statements by testing SQLSTATE instead of SQLCODE.
Hope this was helpful.
Information about DB2 SQL Error Codes and Error Messages on Windows, Linux and Z/OS Operating Systems.