Re: SQL Indicator Arrays

What would be nicer, imho, is if we didn't have to keep track of those null indicators - let the system do it. Provide us with a function %isNull(fieldname) or something, and let it figure it out. Sooo much simpler.

--
*Peter Dow* /
Dow Software Services, Inc.
909 793-9050
petercdow@xxxxxxxxx <mailto:petercdow@xxxxxxxxx>
pdow@xxxxxxxxxxxxxx <mailto:pdow@xxxxxxxxxxxxxx> /


On 11/17/2016 12:27 PM, dlclark@xxxxxxxxxxxxxxxx wrote:

"MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx> wrote on 11/16/2016
11:15:45 AM:

On the flip side, it is a nuisance (to me) to have to manually
create and maintain such a data structure. So, has anybody come up with

a

means of automatically generating an SQL indicator array with an

overlaid

data structure that matches the RPG-generated data structure for an
external SQL view reference? If not, maybe it is time for an RFE?

I created the RFE for an extension to the LIKEDS keyword to
support this.

http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=97462

It would also be great, though, if the SQL precompiler would be
consistent in what it requires for the different ways that the parameter
list can be coded. At the very least it should support a subscripted
element from the indicator array the same as a named SQL indicator.
However, I agree that subscripted SQL indicators can be error-prone if
they have to be hand-coded and that is why named SQL indicators are great.
Conversely, if it could iterate the subfields of a data structure the
same way that it can iterate an SQL indicator array then that would be
great, too.

Sincerely,

Dave Clark