SQLCODE -303: Output variable type not compatible

What it means

A FETCH, SELECT INTO, VALUES INTO, SET or CALL moves each value in the result into the matching host variable in the INTO list. The first value goes into the first variable, the second into the second, and so on. Each pair has to be compatible. Numbers go into numeric or character host variables. Character strings go into character host variables. Dates, times and timestamps go into character fields long enough to hold them.

When a pair doesn't fit, Db2 stops with -303 and gives the position of the host variable in the INTO list, counted from 1. The check is on data types only. A number that has the right type but is too big gives -304 instead.

Because the pairing is by position, one missing or extra column in the SELECT list shifts every value after it into the wrong variable. The first type mismatch then shows up as -303, even though the real mistake is somewhere earlier.

Common causes

• The SELECT list and INTO list are out of step, often after a column was added to or removed from one of them.
• SELECT * was used and the table gained or lost a column, or its columns are in a different order in this environment.
• A character column is fetched into a numeric host variable, or a numeric column into a binary one.
• The DCLGEN copybook is out of date, so a host variable has an old data type after the column was altered.
• A dynamic SQL program built its SQLDA with types that don't match the described result columns.

How to find the problem

1. Read the position in the DSNT408I message, then count along the INTO list to that host variable.
2. Line up the SELECT list and the INTO list side by side. Check that they have the same number of items in the same order.
3. Compare the host variable's declaration with the column type in SYSIBM.SYSCOLUMNS, or with the current DCLGEN.
4. For dynamic SQL, compare the SQLDA after DESCRIBE with what the program sets before FETCH.

How to fix it

• Make the SELECT list and the INTO list match one for one.
• Name the columns instead of using SELECT *, so a table change can't shift the values.
• Regenerate the DCLGEN after a table change, update the program, then precompile and bind again.
• Declare the host variable with a compatible type, or use CAST or CHAR in the SELECT list to return the type the program expects.

What it looks like

DSNT408I SQLCODE = -303, ERROR:  A VALUE CANNOT BE ASSIGNED TO VARIABLE NUMBER 4 BECAUSE THE
         DATA TYPES ARE NOT COMPATIBLE
DSNT418I SQLSTATE   = 42806 SQLSTATE RETURN CODE

Technical reviewer: Albert Joseph, WND Software.

Last reviewed 2026-10-18 by the WND Software team. Written in our own words. For the full reference, check IBM’s Db2 for z/OS documentation for your release.