It was with one of the last TRs AFAIK.
And the type conversation rules are pretty straightforward - '1' means true and '0' means false - that seems fully compatible to RPG type IND.
But I also tried to compare like ":bool = '1'" and other ideas. To make it work, I have to use a CHAR(1) variable - IND doesn't work in any combination.
We're already opening a support case with IBM - hopefully we will get some results.
We also have some other problems with SQL right now, like with OVER() and LEFT JOIN in the same query - so we're preparing more than one case at the moment.
Thanks for your thoughts.
Kind regards,
Daniel
Original Message:
Sent: 2/24/2024 2:19:00 PM
From: Robert Cozzi
Subject: RE: SQLCODE -311 with VARCHAR and BOOLEAN in WHERE clause (since 7.5)
Just a note: And RPG "indicator" variable is a character variable to SQL. Not a true "bool" I remember reading an RFE to add true BOOLEAN variables to SQL a while ago but don't know if they're implemented as yet.
Try changing the boolean variable from IND to INT(10) and and use 1 to turn it on/true.
------------------------------
Robert Cozzi
------------------------------
Original Message:
Sent: Fri February 09, 2024 09:25 AM
From: Daniel Gross
Subject: SQLCODE -311 with VARCHAR and BOOLEAN in WHERE clause (since 7.5)
Thanks Christian.
We already testet this in every thinkable configuration, but always the same problem.
Strange thing is - if you clear the generated field "SQL_00004" before executing the SQL in the procedure, everything works find. But "SQL_00004" is only a buffer in the generated unnamed static data structure - no host-variable.
Also strange is - it works outside of a procedure (in the cycle main procedure) without problems. But in this case, the generated data structure is not marked as "STATIC" - which might be the problem, but we can't do very much about that.
Long story short - we're already in the process of sending this defect to IBM ...
Our admin team is applying latest PTFs today - but after your tests, I have no high-hopes that this will help.
Anyway - thanks for your effort.
Kind regards,
Daniel
------------------------------
Daniel Gross
Original Message:
Sent: Fri February 09, 2024 04:39 AM
From: Christian Jorgensen
Subject: SQLCODE -311 with VARCHAR and BOOLEAN in WHERE clause (since 7.5)
Hi Daniel,
I tested your program on my IBM i 7.5 system with all latest PTF groups installed, and I get the same error!
When I recreate your program in a SQL compound statement, it runs without errors:
begin declare sVar varchar( 100 ) default 'Hello'; declare bBool boolean default true; declare nCount integer default 0; select count(*) into nCount from sysibm.sysdummy1 where ' ' = sVar and bBool; call SYSTOOLS.LPRINTF( 'nCount = ' concat nCount );end
The above code writes a joblog entry with the text 'nCount = 0' - as expected.
This is an error in the SQL precompiler or runtime, as I see it, and you should report this to IBM.
Best regards,
Christian
------------------------------
Christian Jorgensen
IT System Administrator
Network of Music Partners A/S
Original Message:
Sent: Wed February 07, 2024 07:14 AM
From: Daniel Gross
Subject: SQLCODE -311 with VARCHAR and BOOLEAN in WHERE clause (since 7.5)
Hi,
I already posted this in another group, and got advice to try it here and in SQL.
I have a strange case in an SQLRPGLE program. Here is my example code, to eventually reproduce this:
**free
ctl-opt actgrp(*new);
dcl-s bBool ind inz(*on);
dcl-s sVar varchar(100) inz('Hello');
dcl-s nCount int(10) inz;
prTest();
prTest();
*inlr = *on;
return;
dcl-proc prTest;
exec sql select count(*)
into :nCount
from sysibm.sysdummy1
where ' ' = :sVar and :bBool ;
return;
end-proc;
When running/debugging the program, the SQLCODE is *ZERO after the first procedure call.
But after the second procedure call, the SQLCODE is -311, which means "Length in varying-length, LOB, or XML host variable not valid".
If I remove either the Boolean or the Varchar variable from the statement, it runs fine. Changing ":bBool" to ":bBool = '1'" or anything else doesn't help.
If I add the line
sql_00004 = *blank;
just before the EXEC SQL it runs also fine. This is the buffer before the VARCHAR field in the SQL host variables DS, that the Pre-Compiler defines. And the content of this "buffer" is the only thing that differs from call 1 to call 2.
But this shouldn't happen? Or should it? What am I doing wrong?
From what I can see, it happens only, if the program was compiled on 7.5. If it was compiled on an earlier release, it seems to run fine on 7.5.
TIA for every hint.
Daniel
#RPG