DB2 SQL Errors Codes and Error Messages and Warnings from Error +252 to +335

Error: DB2 SQL Error: SQLCODE=+252, SQLSTATE=01659, SQLERRMC=TBSPACEID=, TABLEID=, COLNO=, DRIVER=
A NON-ATOMIC statement
STATEMENT SUCCESSFULLY
PROCESSED ALL REQUESTED ROWS,
WITH ONE OR MORE WARNING
CONDITIONS
Explanation: A non-atomic statement statement
successfully processed multiple rows of data. However,
one or more warning conditions occurred. Use GET
DIAGNOSTICS to obtain information about the
warning conditions that occurred.
System action: The statement was processed.
Programmer response: Analyze the warning
conditions to determine whether the statement should
be rolled back or not.
SQLSTATE: 01659

Error: DB2 SQL Error: SQLCODE=+304, SQLSTATE=01515, SQLERRMC=TBSPACEID=, TABLEID=, COLNO=, DRIVER=
A VALUE WITH DATA TYPE data-type1
CANNOT BE ASSIGNED TO A HOST
VARIABLE BECAUSE THE VALUE IS
NOT WITHIN THE RANGE OF THE
HOST VARIABLE IN POSITION
position-number WITH DATA TYPE
data-type2
Explanation: A FETCH or SELECT into a host variable
list or structure, position number position-number failed
because the host variable having data type data-type2
was not large enough to hold the retrieved value
having data type data-type1.
System action: The FETCH or SELECT could not
return the data for the indicated SELECT item, the
indicator variable is set to negative two (-2) to indicate
a null value returned. Processing continues.
Programmer response: Verify that table definitions are
current, and that the host variable has the proper data
type. See the explanation for SQLCODE -405 for ranges
of SQL data types.
SQLSTATE: 01515

Error: DB2 SQL Error: SQLCODE=+331, SQLSTATE=01520, SQLERRMC=TBSPACEID=, TABLEID=, COLNO=, DRIVER=
THE NULL VALUE HAS BEEN
ASSIGNED TO A HOST VARIABLE
OR PARAMETER BECAUSE THE
STRING CANNOT BE CONVERTED
FROM source-ccsid TO target-ccsid.
REASON reason-code, POSITION
position-number
Explanation: A string had to be converted from
source-ccsid to target-ccsid and an error occurred during
the conversion. The position-number, if provided
(non-zero), is the ordinality of the host variable or
parameter in the SQLDA. See the description of
SQLCODE -331 for further information including the
meaning of the reason-code.
System action: The host variable is unchanged and its
indicator variable is set to -2 to indicate that a null
value is returned. Execution of the statement continues
as if the conversion error had not occurred.
SQLSTATE: 01520

Error: DB2 SQL Error: SQLCODE=+335, SQLSTATE=01517, SQLERRMC=TBSPACEID=, TABLEID=, COLNO=, DRIVER=
DB2 CONVERTED A HOST
VARIABLE, PARAMETER, OR
COLUMN NUMBER var-num
var-name-or-num TO COLUMN NAME,
HOST VARIABLE, OR EXPRESSION
NUMBER col-name-or-num FROM from
ccsid TO to-ccsid, AND RESULTING IN
SUBSTITUTION CHARACTERS.
Explanation: A conversion error occurred during the
conversion of a string to a different coded character set.
One or more substitution characters have been placed
in the string during the conversion process.
System action: DB2 processes the statement
successfully.
Programmer response: This warning can occur in two
situations:
v If trace for IFCID 136 or 168 is not active, DB2
processes the SQL statement, but used substitution
characters instead one or more characters as a result
of character conversion from from ccsid to to-ccsid. If
substitution is acceptable, no action is necessary. If
substitution is not acceptable, issue a ROLLBACK.
Ensure that data being provided to DB2 is
convertible from from ccsid to to-ccsid without data
loss.
v If trace for IFCID 136 or 168 is active, and the to-ccsid
token is an EBCDIC CCSID, and system parameter
UIFCIDS is OFF, then this warning is caused by the
conversion to EBCDIC CCSID for IFCID trace record.
Use GET DIAGNOSTICS to determine if the original
SQL string had any other warnings associated with
it. If GET DIAGNOSTICS returns no other warnings,
no action is required.
SQLSTATE: 01517

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

 

DB2 SQL Errors Codes and Error Messages and Warnings from Error +237 to +239

SQLServerF1

Error: DB2 SQL Error: SQLCODE=+237, SQLSTATE=01594, SQLERRMC=TBSPACEID=, TABLEID=, COLNO=, DRIVER=
SQLDA INCLUDES integer1 SQLVAR
ENTRIES, BUT integer2 ARE
REQUIRED BECAUSE AT LEAST ONE
OF THE COLUMNS BEING
DESCRIBED IS A DISTINCT TYPE
Explanation: Given that at least one of the columns
being described is a distinct type, space should be
provided for the extended SQLVAR entries in addition to
the base SQLVAR entries. The value of SQLN, integer1,
indicates that there are not enough SQLVAR entries for
the base and extended SQLVAR entries.
The total number of SQLVAR entries that are required
depends on whether USING BOTH was specified (n is
the number of columns being described):
v With USING BOTH, space should be allocated for 3n
SQLVAR entries.
v Otherwise, space should be allocated for 2n SQLVAR
entries.
The number of SQLVAR entries that are needed to
return all of the information about the columns is
integer2.
Attention: In the case of DESCRIBE INPUT, each
reference to column would actually be parameter.
System action: DB2 has set the SQLDAID 7th byte
flag “on” because sufficient space was not provided for
the extended SQLVAR entries. The value of the 7th byte
flag indicates how many SQLVAR entries are needed
for each column. Additionally, because there were
enough SQLVAR entries for the base SQLVARs, DB2 has
set the fields of the base SQLVAR entries. However, DB2
has not set any extended SQLVAR entries.
Programmer response: If there is no need for the
additional information about the distinct type(s), then
no action is required unless USING BOTH was
specified (in which case additional SQLVAR entries
must be provided for the labels).
If the distinct type information is needed, the value of
the SQLN field in the SQLDA should be increased to
integer2 (after making sure that the SQLDA is large
enough to support that amount) and the statement
should be resubmitted.
SQLSTATE: 01594

Error: DB2 SQL Error: SQLCODE=+238, SQLSTATE=01005, SQLERRMC=TBSPACEID=, TABLEID=, COLNO=, DRIVER=
SQLDA INCLUDES integer1 SQLVAR
ENTRIES, BUT integer2 SQLVAR
ENTRIES ARE NEEDED FOR integer3
COLUMNS BECAUSE AT LEAST ONE
OF THE COLUMNS BEING
DESCRIBED IS A LOB
Explanation: Given that at least one the columns
being described is a LOB, space must be provided for
the extended SQLVAR entries in addition to the base
SQLVAR entries. The value of SQLN, integer1, indicates
that there are not enough SQLVAR entries for the base
and extended SQLVAR entries. One or more of the
columns being described may be a distinct type.
The total number of SQLVAR entries that are required
depends on whether USING BOTH was specified or
not (n is the number of columns being described which
is integer3), and whether the columns include any
distinct types:
v With USING BOTH, and one or more distinct types,
space should be allocated for 3n SQLVAR entries.
v Otherwise, space should be allocated for 2n SQLVAR
entries.
The number of SQLVAR entries that are needed to
return all of the information about the columns is
integer2.
Important: In the case of DESCRIBE INPUT, each
reference to column would actually be parameter.
System action: DB2 has set the SQLDAID 7th byte
flag “on” because sufficient space was not provided for
the extended SQLVAR entries. The value of the 7th byte
flag indicates how many SQLVAR entries are needed
for each column. DB2 has not set any SQLVAR entries.
Programmer response: Increase the value of the SQLN
field in the SQLDA to integer2 (after making sure that
the SQLDA is large enough to support that amount)
and resubmit the statement.
SQLSTATE: 01005

Error: DB2 SQL Error: SQLCODE=+239, SQLSTATE=01005, SQLERRMC=TBSPACEID=, TABLEID=, COLNO=, DRIVER=
SQLDA INCLUDES integer1 SQLVAR
ENTRIES, BUT integer2 ARE
REQUIRED FOR integer3 COLUMNS
BECAUSE AT LEAST ONE OF THE
COLUMNS BEING DESCRIBED IS A
DISTINCT TYPE
Explanation: Given that at least one of the columns
being described is a distinct type, space should be
provided for the extended SQLVAR entries in addition to
the base SQLVAR entries. The value of SQLN, integer1,
indicates that there are not enough SQLVAR entries for
the base and extended SQLVAR entries.
The total number of SQLVAR entries that are required
depends on whether USING BOTH was specified or
not (n is the number of columns being described which
is integer3),
v With USING BOTH, space should be allocated for 3n
SQLVAR entries.
v Otherwise, space should be allocated for 2n SQLVAR
entries.
The number of SQLVAR entries that are needed to
return all of the information about the columns is
integer2.
Note: in the case of DESCRIBE INPUT, each reference
to column would actually be parameter.
System action: DB2 has set the SQLDAID 7th byte
flag “on” because sufficient space was not provided for
the extended SQLVAR entries. The value of the 7th byte
flag indicates how many SQLVAR entries are needed
for each column. DB2 has not set any SQLVAR entries.
:elq.
Programmer response: If the distinct type information
is needed, the value of the SQLN field in the SQLDA
should be increased to integer2 (after making sure the
SQLDA is large enough to support that amount) and
the statement should be resubmitted.
If there is no need for the additional information about
the distinct type(s) in the result set, then it is possible
to resubmit the statement only providing enough
SQLVAR entries to accommodate the number of
columns being described (i.e. provide the necessary
number of base SQL entries).
SQLSTATE: 01005

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

 

DB2 SQL Errors Codes and Error Messages and Warnings from Error +220 to +236

SQLServerF1

Error: DB2 SQL Error: SQLCODE=+220, SQLSTATE=01546, SQLERRMC=TBSPACEID=, TABLEID=, COLNO=, DRIVER=
THE COLUMN column-name IN
EXPLANATION TABLE table-name IS
NOT DEFINED PROPERLY
Explanation: An error occurred during the insertion of
a row into the explanation table. The table is
improperly defined for the following reasons:
v A column is missing.
v Columns are defined in the wrong order.
v The table contains an extra column.
v A column description is invalid because of its name,
data type, length, or null attributes.
System action: A valid plan or package will be
created if no errors are detected. The statement is
bound dynamically on each execution of the statement.
Programmer response: For better performance, rebind
the plan or package after correcting the statement. To
correct the statement, correct the definition of the
required explanation table. Refer to chapter 2 of SQL
Reference for information about defining an explanation
table.
SQLSTATE: 01546

Error: DB2 SQL Error: SQLCODE=+222, SQLSTATE=02502, SQLERRMC=TBSPACEID=, TABLEID=, COLNO=, DRIVER=
HOLE DETECTED USING CURSOR
cursor-name
Explanation: A delete hole or an update hole has been
detected while processing a FETCH for cursor
cursor-name. With a SENSITIVE STATIC cursor, a delete
hole occurs when DB2 tries to refetch a row from the
database for a cursor and finds that the corresponding
row of the underlying table has been deleted. An
update hole occurs when DB2 tries to refetch a row
from the database for a cursor and finds that the
corresponding row of the underlying table no longer
satisfies the search condition.
cursor-name
Name of the cursor used for the FETCH
statement.
System action: The statement cannot be processed,
and no data is fetched. The cursor is repositioned on
the hole.
Programmer response: Correct the application
program to handle this situation, or change isolation
levels so the base row cannot be deleted during the
cursor operation.
SQLSTATE: 02502

Error: DB2 SQL Error: SQLCODE=+231, SQLSTATE=02000, SQLERRMC=TBSPACEID=, TABLEID=, COLNO=, DRIVER=
CURRENT POSITION OF CURSOR
cursor-name IS NOT VALID FOR THE
SPECIFIED FETCH ORIENTATION OF
THE CURRENT ROW OR ROWSET
Explanation: The cursor was not positioned on a row
or rowset, and one of the following fetch orientations
specified that the cursor was to be positioned relative
to its current position:
v CURRENT or CURRENT ROWSET
v RELATIVE 0 or ROWSET STARTING AT RELATIVE
0
cursor-name
Name of the cursor used for the FETCH
statement.
System action: The statement cannot be processed. No
data was fetched, and the cursor position is unchanged.
Programmer response: Correct the application
program to establish a valid cursor position before
issuing this FETCH statement.
SQLSTATE: 02000

Error: DB2 SQL Error: SQLCODE=+236, SQLSTATE=01005, SQLERRMC=TBSPACEID=, TABLEID=, COLNO=, DRIVER=
SQLDA INCLUDES integer1 SQLVAR
ENTRIES, BUT integer2 ARE
REQUIRED FOR integer3 COLUMNS
Explanation: The value of the SQLN field of the
SQLDA should be at least as large as the number of
columns being described. integer3 is the number of
columns being described.
In the case that USING BOTH has been specified, twice
as many SQLVAR entries are needed as the number of
columns being described.
The number of SQLVAR entries that are needed to
return all of the information about the columns is
integer2.
Attention: In the case of DESCRIBE INPUT, each
reference to column would actually be parameter.
System action: The SQLDAID 7th byte has been set to
“on” with a value of 2 indicating that 2 SQLVAR entries
are needed for each column. DB2 has not set any
SQLVAR entries.
Programmer response: Increase the value of the SQLN
field in the SQLDA to the value indicated in the
message (making sure the SQLDA is large enough to
support that amount) and resubmit the statement.
SQLSTATE: 01005

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

 

DB2 SQL Errors Codes and Error Messages and Warnings from Error +111 to +204

Error: DB2 SQL Error: SQLCODE=+111, SQLSTATE=01590, SQLERRMC=TBSPACEID=, TABLEID=, COLNO=, DRIVER=
THE SUBPAGES OPTION IS NOT
SUPPORTED FOR TYPE 2 INDEXES
Explanation: You cannot use the SUBPAGES option
for type 2 indexes.
System action: The option is ignored and processing
continues.
Programmer response: Remove the SUBPAGES option
to get rid of the warning.
SQLSTATE: 01590

Error: DB2 SQL Error: SQLCODE=+117 , SQLSTATE=01525, SQLERRMC=TBSPACEID=, TABLEID=, COLNO=, DRIVER=
THE NUMBER OF INSERT VALUES IS
NOT THE SAME AS THE NUMBER OF
OBJECT COLUMNS
Explanation: The number of insert values in the value
list of the insert operation is not the same as the
number of object columns specified.
System action: A valid plan or package will be
created if no errors are detected. The statement is
bound dynamically on each execution of the statement.
Programmer response: For better performance, rebind
the plan or package after correcting the statement. To
correct the statement, specify one and only one value
for each of the specified object columns.
SQLSTATE: 01525

Error: DB2 SQL Error: SQLCODE=+162 , SQLSTATE=01514, SQLERRMC=TBSPACEID=, TABLEID=, COLNO=, DRIVER=
TABLESPACE database-name.tablespacename
HAS BEEN PLACED IN CHECK
PENDING
Explanation: The indicated table space is in check
pending status because the ALTER TABLE statement
was used to specify either of the following:
v A referential constraint
v A check constraint, when the CURRENT RULES
special register is set to ‘DB2’
The table space is not generally available until the
check pending status is removed from the table space.
System action: The table space was placed in check
pending status.
Programmer response: Run the CHECK DATA utility.
The enforcement of the referential constraint or the
check constraint is deferred until the CHECK DATA
utility is run.
SQLSTATE: 01514
Error: DB2 SQL Error: SQLCODE=+203 , SQLSTATE=01552, SQLERRMC=TBSPACEID=, TABLEID=, COLNO=, DRIVER=
THE QUALIFIED COLUMN NAME
column-name WAS RESOLVED USING A
NON-UNIQUE OR UNEXPOSED
NAME
Explanation: The table designator selected to resolve a
qualified column name is one of the following:
v An unexposed name
v An exposed name that has an exposed duplicate in
the same FROM clause
v An exposed name that has an unexposed duplicate
which appears before the selected name in the
ordered list of names to which the qualifier is
compared
Therefore, the statement does not conform to the
guidelines for using only unique exposed names as
qualifiers or it is possible that the column reference was
not resolved to the intended instance of the table or
view.
System action: DB2 uses the selected name to resolve
the reference.
Programmer response: If DB2’s resolution of the
qualifier was not what you intended, rewrite the SQL
statement and submit it again. The rules used to
resolve column name qualifiers are given in chapter 2
of SQL Reference .
SQLSTATE: 01552

Error: DB2 SQL Error: SQLCODE=+204 , SQLSTATE=01532, SQLERRMC=TBSPACEID=, TABLEID=, COLNO=, DRIVER=
name IS AN UNDEFINED NAME
Explanation: The object identified by name is not
defined in the DB2 subsystem. This return code can be
generated for any type of DB2 object.
System action: A valid plan or package will be
created if no errors are detected. The statement is
bound dynamically on each execution of the statement.
Programmer response: For better performance, rebind
the plan or package after correcting the statement. To
correct the statement, determine that the object name
was correctly specified in the SQL statement (including
any required qualifiers). If so, ensure that the object
exists in the system before resubmitting the statement.
SQLSTATE: 01532

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

 

 

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.