mridoni / gixsql

GixSQL is an ESQL preprocessor and a series of runtime libraries to enable GnuCOBOL to access PostgreSQL, ODBC, MySQL, Oracle and SQLite databases.
GNU General Public License v3.0
16 stars 8 forks source link

wrong generated COBOL in 1.0.16 #83

Closed GitMensch closed 2 years ago

GitMensch commented 2 years ago

I'm a bit confused because in one environment everything seems to work, while in another it doesn't but generate SQL definitions like the following, which of course raise a compiler error then:

GIXSQL 01  SQ0031.
GIXSQL     02  FILLER PIC X(0030) VALUE "DELETE FROM POS WHERE OID = $1".
GIXSQL     02  FILLER PIC X(1) VALUE X"00".

...

GIXSQL*    EXEC SQL
GIXSQL*        DELETE FROM POS
GIXSQL*        WHERE OID = :OID
GIXSQL*    END-EXEC.
GIXSQL     CALL "GIXSQLStartSQL"
GIXSQL     END-CALL
GIXSQL     CALL "GIXSQLSetSQLParams" USING
GIXSQL         BY VALUE 22
GIXSQL         BY VALUE 9
GIXSQL         BY VALUE 0
GIXSQL         BY VALUE 0
GIXSQL         BY REFERENCE OID
GIXSQL     END-CALL
GIXSQL     CALL "GIXSQLExecParams" USING
GIXSQL         BY REFERENCE SQLCA
GIXSQL         BY REFERENCE x"00"
GIXSQL         BY VALUE 0
GIXSQL         BY REFERENCE SQ0031
GIXSQL         BY VALUE 1
GIXSQL     END-CALL
GIXSQL     CALL "GIXSQLEndSQL"
GIXSQL     END-CALL.

Any idea what is happening / broken in this environment? Or is it gixpp to be blamed with a command that has exactly this length / layout?

mridoni commented 2 years ago

Is by any chance the definition in the first line > 72 bytes long? Yesterday, while working on another issue I found something similar. I thought it was a corner case so I took a note and went on with what I was doing, but maybe it deserves a more accurate investigation.

GitMensch commented 2 years ago

The generated definition is 73 bytes long, yes.

mridoni commented 2 years ago

Ok, I reproduced it

mridoni commented 2 years ago

Fixed in the internal repository, will be in in v1.0.17

GitMensch commented 2 years ago

Fixed in 1.0.17