I know defining a sqltype(clob:xx) field causes the RPG compiler to generate related fields with _data and _len.  If setting the clob in RPG, you'd want to set those 2 fields and then the clob field can be used in SQL statements.

I recall seeing a error situation when I tried to directly access the clob field outside a SQL statement (regular RPG lines of code).  I looked into documentation but didn't see anything directly stating this.  I just ran a test and using the clob in RPG worked, but I'm nervous that something I experienced in the past could become a problem if I do this.  Maybe there was a fix, or maybe I'm "just getting lucky" in my test now, but I want to be certain of the technique that should be used.

My question is: can I directly access this type of field outside a SQL statement, or should I always use the _data/_len fields in that situation?

Thanks!

------------------------------
Dave Weissman
------------------------------

#SQL

Original Message:
Sent: 11/15/2022 11:46:00 AM
From: Dave Weissman
Subject: SQLRPGLE - CLOB

I know defining a sqltype(clob:xx) field causes the RPG compiler to generate related fields with _data and _len.  If setting the clob in RPG, you'd want to set those 2 fields and then the clob field can be used in SQL statements.

I recall seeing a error situation when I tried to directly access the clob field outside a SQL statement (regular RPG lines of code).  I looked into documentation but didn't see anything directly stating this.  I just ran a test and using the clob in RPG worked, but I'm nervous that something I experienced in the past could become a problem if I do this.  Maybe there was a fix, or maybe I'm "just getting lucky" in my test now, but I want to be certain of the technique that should be used.

My question is: can I directly access this type of field outside a SQL statement, or should I always use the _data/_len fields in that situation?

Thanks!

------------------------------
Dave Weissman
------------------------------

#SQL

thank you for your reply and for clarifying

------------------------------
Dave Weissman
------------------------------

Original Message:
Sent: Tue November 15, 2022 04:41 PM
From: Birgitta Hauser
Subject: SQLRPGLE - CLOB

The stand alone field is converted by the pre-compiler into a Data structure, i.e.

 

//* DCL-S MyClob SQLTYPE(CLOB: 100000);

DCL-DS MyClob;

   MyClob_Len  Uns(10);

   MyClob_Data  Char(100000) CCSID(*JOBRUNMIX);

END-DS;

 

In your RPG Program you can use MYCLOB like any other data structure and the subfield MYCLOB_LEN and MYCLOB_DATA like any other data structure subfields.

 

Mit freundlichen Grüßen / Best regards

 

Birgitta Hauser

Modernization – Education – Consulting on IBM i

 

"Shoot for the moon, even if you miss, you'll land among the stars." (Les Brown)

"If you think education is expensive, try ignorance." (Derek Bok)

"What is worse than training your staff and losing them? Not training them and keeping them!"

„Train people well enough so they can leave, treat them well enough so they don't want to." (Richard Branson)

 

 

Original Message:
Sent: 11/15/2022 11:46:00 AM
From: Dave Weissman
Subject: SQLRPGLE - CLOB

I know defining a sqltype(clob:xx) field causes the RPG compiler to generate related fields with _data and _len.  If setting the clob in RPG, you'd want to set those 2 fields and then the clob field can be used in SQL statements.

I recall seeing a error situation when I tried to directly access the clob field outside a SQL statement (regular RPG lines of code).  I looked into documentation but didn't see anything directly stating this.  I just ran a test and using the clob in RPG worked, but I'm nervous that something I experienced in the past could become a problem if I do this.  Maybe there was a fix, or maybe I'm "just getting lucky" in my test now, but I want to be certain of the technique that should be used.

My question is: can I directly access this type of field outside a SQL statement, or should I always use the _data/_len fields in that situation?

Thanks!

------------------------------
Dave Weissman
------------------------------

#SQL