Oppolzer - Informatik / Blog

Same behaviour for DB2 V9.5 on Windows;
I guess, none of the DB2 LUW flavors sets SQLERRD(5)
on SQL syntax errors.

So, back to the original question: setting SQLCODE +98 for a
terminating semicolon does not make much sense on DB2 LUW,
because DB2 LUW does not support the SQLERRD(5) logic -
you will not get the position of the semicolon back, and that is what
the SQLCODE +98 is used for, at least by DSNTIAUL.

I'll stick with the "mainframe only" solution in my ETL tool ... only on
DB2 z/OS the error position is sent back to the user on DB2
syntax errors ...

Kind regards

Bernd



Am 16.01.2015 um 15:42 schrieb Bernd Oppolzer:
> It seems as if only DB2 z/OS tells the location of syntax errors in the SQL statement
> in SQLERRD (5), following PREPARE.
>
> It has yet to be confirmed for Windows, but my old DB2 on OS/2 does the following:
>
> -104 in SQLCODE on some syntax error (which is a good example, because I know
> for sure, that DB2 on z/OS gives the location in SQLERRD (5) in this case; same goes
> for SQLCODE -199)
>
> - zero in SQLERRD (5) ... which is different from what DB2 on z/OS does
>
> - in SQLERRMC, we get three informations:
>
> a) the symbol that caused the syntax error
> b) some symbols read before (which is helpful, 20 chars ca.)
> c) some symbols which would have been ok in this place
>
> the informations are separated by X'FF', as usual
>
> Of course, you can scan the SQL statement for the 20 chars from SQLERRMC and
> try to find the missing information from SQLERRD (5) this way, but this is not as convenient
> as on z/OS, and it would be a problem, if the statement part shown is not unique throughout
> the SQL statement.
>
> I will test it on DB2 for Windows 9.5 later this day.
>
> Kind regards
>
> Bernd
>