Until we got %scanrpl(), we had to do a loop to get the same capability

I reckon you've put the loop into a procedure, so you only need to code it
once.

On Wed, Dec 3, 2014 at 2:50 PM, Vernon Hamberg <vhamberg@xxxxxxxxxxxxxxx>
wrote:

Hi John

I think I can't go along with some of your concerns around using SQL
functions. If I may say, it sounds like a desire for purity of language
without, for me, much benefit.

If there is an SQL function that does what I want better than something
"simple" in RPG, I'll probably use it. An example for years was the
replace() SQL function, which replaced every instance of the search string
with the replacement string. Until we got %scanrpl(), we had to do a loop
to get the same capability, and it was prone to boundary-issue errors.

I find the matter of source member type not to have much bearing - and if
that's the only one of the "... all kinds of dependencies...", well, I'd
like to hear what the others are - really, I would. I run into the member
type thing sometimes in my work, when I want to add SQL stuff to existing
non-SQL RPG - it is an inconvenience, even in, or especially because of, an
SCM app, where we don't usually go directly to setting the member type -
oh, well, it's been worth it.

BTW, what are the other IBM i languages that have date math that don't
need SQL functions? If Java, as I suppose, well, do we want to urge going
exclusively to Java? And a lot of calls out of RPG to Java methods can
perform not so well - look at using Scott's POI wrapper for doing largish
spreadsheets - not too good!

Now as to SQL/PL - at 7.2 now, we have dynamic compound statements - I
actually really like the simplicity of some database stuff in stored
procedures, and this lets us put a LOT of SQL statements and assignments
and all into one EXEC SQL - nice, at least, IMO.

Whew! Way too much to have said on this - gotta get to work!

Later
Vern

On 12/3/2014 7:16 AM, John E wrote:

I agree that to be able to "tweak", in this context, has not much use
(e.g.
you want day 1 to be sunday).

But if you want to use SQL for everything if there is some function
provided, then why not throw RPG out altogether and program everthing in
SQL/PL?

It's not the "preprocessor" machinery, it's having all kinds of
dependencies etc. For example you need to change the member type from
RPGLE
to SQLRPGLE, because you need to do some date math. When the program runs,
the SQL runtime machinery is also initialized, just for some date maths,
which in every other language you don't need to resort to embedded SQL
Maybe it's optimzed that if you only call some functions it has no
overhead, but i don't know, etc..

Use SQL for DB tasks, use RPG for the rest.

-snip really long source code example- :)

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].