Re: Populating fixed-length fields from IBM DB2 Services OBJECT_STATISTICS

[Vern Hamberg <vhamberg@xxxxxxxxxxxxxxx>]

Joe

If you were pulling in an entire table with SQL, you should be able to 
declare a DS based on the table that SQL can use, not just for native 
RPG I/O - you hinted at the issue in your original post.

But in this case you are pulling only a couple of the columns, so you 
have to define the VARCHAR stuff yourself, right?

I feel kind of redundant in my reply!!

Cheers
Vern

On 3/8/2021 4:59 PM, Joe Pluta wrote:
> Yes, that's probably what I'll do.  If I use a DS defined like(record) 
> for the file I/O and a DS with VARCHAR for the SQL, I can hopefully do 
> EVAL-CORR between the two.
>
>
> On 3/8/2021 4:52 PM, Joep Beckeringh via RPG400-L wrote:
> > Joe,
> >
> > My 'workaround' is to fetch into a (qualified) data structure with 
> > fields that match the definition, and then move the data to database 
> > fields (mostly in a qualified data structure as well).
> >
> > Joep Beckeringh
> >
> >
> > Op 8-3-2021 om 22:43 schreef Joe Pluta:
> > > Hit my head against a wall for three hours today, so thought I'd 
> > > bring it to the list to try to save someone else time.
> > >
> > > I have a physical file with (among others) fields OZLIB and OZOBJ.  
> > > These are the library name and object name, and both are defined as 
> > > 10A.  Declaring a cursor like this: SELECT OBJLIB, OBJNAME from 
> > > TABLE(OBJECT_STATISTICS('MYLIB', 'ALL')) works wonderfully as long 
> > > as I do FETCH NEXT FROM C INTO :OZLIB, :OZOBJ.  But as soon as I 
> > > stick those two fields (OZLIB amd OZOBJ) into a data structure, I 
> > > get the dreaded "unusable" message telling me that a subfield 
> > > doesn't match.
> > >
> > > Well, after a whole lot of hair-pulling, I figured it out. The 
> > > fields in OBJECT_STATISTICS are defined as VARCHAR, and while 
> > > embedded SQL will convert VARCHAR to fixed-length if you specify 
> > > individual fields (albeit with a warning at runtime about 
> > > potentially poor performance), it won't do so on a data structure.  
> > > The matching rules are much stricter, probably because it assembles 
> > > the data from SQL and then moves it as a single block of memory into 
> > > the data structure (although I'm guessing there).
> > >
> > > Anyway, since I don't plan to standardize on VARCHAR fields in my 
> > > databse, my workaround is to do all the fields individually. When I 
> > > have time I'll try defining the fields with the same name but with 
> > > VARCHAR in a qualified DS and then try an EVAL-CORR.