SQLRPGLE and qualified DS doesn't work?
Charles Wilt
structure with SQL" I'm still fighting the same requirement.
Trying different methods, one of which involved nested data structures,
so my main DS needed to be qualified. I attempt use this qualified DS
for my SQL "select into " but the precompiler doesn't properly qualify
the DS subfields, so the RPG compiler complains about undefined names.
Can anyone confirm that this is working as designed?
Any thoughts/comments on this or my other post?
Thanks,
Charles Wilt
Kent Milligan
the next release, so I believe the answer is "Working as designed" for V5R2.
--
Kent Milligan, DB2 & BI team
PartnerWorld for Developers, iSeries
km...@us.eye-bee-m.com (spam trick) GO HAWKEYES!!
>>> www.iseries.ibm.com/db2
(opinions stated are not necessarily those of my employer)
Jonathan Ball
> Never did get a reply to my last post, "RPG: Using an array inside data
> structure with SQL" I'm still fighting the same requirement.
>
> Trying different methods, one of which involved nested data structures,
> so my main DS needed to be qualified. I attempt use this qualified DS
> for my SQL "select into " but the precompiler doesn't properly qualify
> the DS subfields, so the RPG compiler complains about undefined names.
I haven't seen nested data structures, so I don't know
what it is. This is just one of many areas where I've
long felt, and still feel, COBOL is superior to RPG, as
COBOL has supported nested tables since the beginning
of the language. (Let's see if this old debate still
has legs...)
Back to the problem at hand, the precompiler apparently
won't recognize *any* host variable name that isn't in
the simple format ':name', with no special characters
other than the leading colon.
>
> Can anyone confirm that this is working as designed?
>
> Any thoughts/comments on this or my other post?
Going back to your other post:
CW:
Am I correct in assuming that this doesn't work?
JB:
Yes. It's because the host data structure must have as
many named fields as there are columns in your SELECT.
CW:
If I define each individual field in the DS, then
overlay them with an array, will that work?
JB:
Yes - pretty as a picture. I just did it, and it
worked as hoped:
D stuff DS
D a 2
D b 2
D c1 1
D c2 1
D c 1 dim(2)
D overlay(stuff:5)
C/exec sql
C+ create table qtemp/somefile
C+ (a char(2), b char(2), c char(1), d char(1))
C/end-exec
C/exec sql
C+ insert into qtemp/somefile
C+ values('aa','bb','1','2')
C/end-exec
c/exec sql
c+ select a,b,c,d
C+ into :a, :b, :c1, :c2
C+ from somefile
C/end-exec
At the conclusion of my SELECT INTO, the elements of
array C contained '1' and '2'.
Charles Wilt
Charles Wilt
Thanks for the replies. I had found another way to do it using based DS
that defined the arrays. Also, I think it would work if I passed the DS
into a procedure.
But using an overlay doesn't require a "dummy" DS, so I'll play with
that. My only problem, is that since I used LIKE(somefield) to define
the DS subfields...I'm going to have to calculate the correct starting
pos myself. Even better, some if not all all packed...
Fun...fun.
BUT, just had a thought, what if I changed the order of the subfields so
that the ones I want to access via an arrays are at the big inning. Then
maybe I could use OVERLAY(MYDS:1) and OVERLAY(MYDS:*NEXT).
Well crap....doesn't seem to work. I notice that the array fields are
included in the precompiler output...(EVAL ARRAYFIELD = SQL_00043). I
wonder if that is the problem. Does your test show the same thing?
Thanks,
Charles
In article <3ECB9231...@whitehouse.not>, jon...@whitehouse.not
says...
Charles Wilt
understood it to. But that's something I can look at later ;-)
Also, I hadn't looked close enough at your code; I didn't realize that
you were passing in the host variables individually. I was still trying
to just pass in the DS. Once I defined the subfields without the LIKE
and passed them in individually, then it worked as expected.
Thanks for your help,
Charles
In article <MPG.19356571a...@news.easynews.com>,
cw...@nospam.miamiluken.com says...
Jonathan Ball
> Ok, apparently the OVERLAY(SOMEDS:*NEXT) doesn't work quite like I
> understood it to. But that's something I can look at later ;-)
>
> Also, I hadn't looked close enough at your code; I didn't realize that
> you were passing in the host variables individually. I was still trying
> to just pass in the DS. Once I defined the subfields without the LIKE
> and passed them in individually, then it worked as expected.
I think you must specify *either* a host structure - a
DS in RPG - or the individual fields; you can't mix
them up. If you specify the host structure, e.g.
select c1, c2, c3,...cn
into :my_ds
from sometable
where ...
then there must be individual fields defined in the DS
for each column specified in the SELECT statement.
>
> Thanks for your help,
You're welcome.
I never did figure out what a "qualified" DS is. Could
you fill me in?
Charles Wilt
example.
d MyDS ds
d field1 2a
d field2 2a
d MyDS1 ds qualified
d field1 2a
d field2 2a
d MyDS2 ds qualified
d fieldA 2a
d fieldB 2a
d dsfield likeds(MyDS1)
With the above definitions, you must use a qualified name to access the
subfields. For example:
eval MyDS1.field1 = 'HI'
eval MyDS2.dsfield.field2 = *BLANKS
Note, this allows for DS subfields to have the same name, as in MyDS &
MYDS1. Also in conjunction with the LIKEDS keyword, it allows you to
nest data structures.
Also you can use DIM at the same time:
d MyDS3 ds qualified dim(10)
d fieldA 2a
d fieldB 2a
d dsfield likeds(MyDS1) dim(1)
eval MyDS3(4).fieldA = 'HI'
eval MyDS3(5).dsfield(3).field1 = *BLANKS
It's new to v5r2 (?), and is covered in the ILE RPG Reference manuals in
Infocenter.
Lastly, just a point to clarify using into :some_ds. I had _MORE_ fields
in the DS than what was on the select. The extra fields were the array
overlay fields. You don't get any error messages during compile, but the
precompiler creates eval statements for all fields in the DS, even though
there is nothing in the select to load them with, nor are they "real" ie.
allocated fields.
HTH,
Charles
In article <3ECD014C...@whitehouse.not>, jon...@whitehouse.not
Jonathan Ball
It looks a little tricky.
At a glance, I'd have to say COBOL multi-dimensional
tables are much friendlier.
01 high-level-structure.
05 nested-structure occurs 12 indexed by A.
10 some-field pic x(002).
10 another-nested-structure occurs 31
indexed by B.
15 some-other-field pic s9(005) comp-3.
15 yet-another-nested-structure occurs 24
indexed by C.
20 yet-another-fld pic x(020).
20 just-one-more pic 9(007).
Procedure Division using month-input, day-input,
hour-input.
set A to month-input.
set B to day-input.
set C to hour-input.
move just-one-more (A, B, C) to someplace.
No matter how COBOL-like RPG gets, it probably will
never catch up on some features.
Charles Wilt
Since the qualified DS matches pretty close to a C structure.
Also, as I mentioned the nesting is only one benefit. The other is it
allows creation of an abstract data type which can be used via the LIKEDS
keyword. Again, this is something C allows.
* An ADT, no storage is actually allocated
d SomeInfoDS ds qualified based(@)
d field1 7s 0
d field2 10a
d BeforeDS ds like(SomeInfoDS)
d AfterDS ds like(SomeInfoDS)
/free
if BeforeDS.field1 <> AfterDS.field2;
//do something
somthing += 1;
SomeProc(AfterDS);
endif;
/end-free
The LIKEDS also comes in handy for passing data structures to procedures.
d SomeProc pr
d info like(SomeInfoDS)
p SomeProc b
d SomeProc pi
d info like(SomeInfoDS)
/free
info.field2 = 'HELLO';
/end-free
p SomeProc e
Charles
In article <3ECDC206...@whitehouse.not>, jon...@whitehouse.not
says...