DB2 SQL Errors Codes and Error Messages and Warnings from Error 000 to +110

SQLServerF1

Error: DB2 SQL Error: SQLCODE=, SQLSTATE=, SQLERRMC=TBSPACEID=, TABLEID=, COLNO=, DRIVER=

000 SUCCESSFUL EXECUTION
Explanation: Unqualified successful execution or
successful execution with one or more warnings. If
SQLWARN0 is blank, there are no warnings. If
SQLWARN0 = W, at least one of the other warning
indicators in the SQLCA has been set to indicate a
warning condition. For example, SQLWARN1 is used to
indicate that a value of a string column was truncated
when assigned to a host variable. SQLWARNx fields
are described in Appendix D of SQL Reference.
SQLSTATE: 00000 for unqualified successful execution
SQLSTATE: 01ddd for successful execution with
warning ‘ddd’.

+012 THE UNQUALIFIED COLUMN NAME
column-name WAS INTERPRETED AS A
CORRELATED REFERENCE
Explanation: The column name does not identify a
column of a table or view in the FROM clause of the
subquery. However, it does identify a column of a table
or view in a FROM clause at a higher level in the
statement.
System action: The column name is interpreted as a
correlated reference.
Programmer response: If DB2’s interpretation of the
column name was not what you intended, rewrite the
SQL statement and submit it again. If you intend the
column name to refer to a table named at a higher
level, we advise rewriting the statement anyway, using
a table name or correlation name as a qualifier for the
column name. The unqualified column name could be
interpreted differently if you do a rebind after altering
one of the tables to which you refer.
SQLSTATE: 01545

+098 A DYNAMIC SQL STATEMENT ENDS
WITH A SEMICOLON.
Explanation: The statement string of a PREPARE or
EXECUTE IMMEDIATE statement is a valid dynamic
SQL statement, but it ends with a semicolon.
System action: The semicolon and any subsequent
text are ignored.
Programmer response: Check that the semicolon is
being used as a statement terminator.
SQLSTATE: 01568

+100 ROW NOT FOUND FOR FETCH,
UPDATE OR DELETE, OR THE
RESULT OF A QUERY IS AN EMPTY
TABLE
Explanation: One of the following conditions
occurred:
v No row met the search conditions specified in an
UPDATE or DELETE statement.
v The result of a SELECT INTO statement was an
empty table.
v The result of the subselect of an INSERT statement is
empty.
v A FETCH statement was executed when the cursor
was positioned after the last row of the result table.
v No available rows qualified for return when SKIP
LOCKED DATA was specified with isolation level CS
or RS.
v A FETCH statement that returns a rowset was
issued, but there were not enough rows after the
current cursor position to reposition the cursor on a
full rowset. The cursor has been positioned on a
partial rowset. If a target was specified, data was
returned only for the number of rows that were
actually fetched for the partial rowset. The number
of rows that were returned is in field SQLERRD3 of
the SQLCA.
When a SELECT statement is executed using SPUFI,
this SQLCODE indicates normal completion.
This SQLCODE is also issued when LOB data cannot
be returned. This situation can occur when an
application is running with isolation level UR and
another application has locked the LOB table space.
System action: No data was retrieved, updated, or
deleted.
SQLSTATE: 02000

+110 SQL UPDATE TO A DATA CAPTURE
TABLE NOT SIGNALED TO
ORIGINATING SUBSYSTEM
Explanation: IMS DataPropagator exit routine issued
an SQL data change statement to a table defined with
DATA CAPTURE CHANGES. Since data capture is
already in progress, notification is not sent back to the
originating IMS subsystem.
System action: DB2 changes the data and records thechange in the log. DB2 does not notify IMS
DataPropagator’s exit routine of the change, because
doing so might cause the same change to be made
again.
SQLSTATE: 01561

Above are list of DB2 SQL Errors and Warnings from Error 000 to +110 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.

Thanks,
SQLServerF1 Team
Information about DB2 SQL Error Codes and Error Messages on Windows, Linux and Z/OS Operating Systems.

 

Leave a Reply

Your email address will not be published. Required fields are marked *