@1: As long as you do not change the parameters of the RPG function, you do
not need to recreate the SQL function (even though I always do so)
@2: An UDF is only deterministic within the same job or connection.

Mit freundlichen Grüßen / Best regards

Birgitta Hauser

"Shoot for the moon, even if you miss, you'll land among the stars." (Les
"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!"

-----Ursprüngliche Nachricht-----
Von: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] Im Auftrag von James Lampert
Gesendet: Wednesday, 05.9 2012 23:28
An: Midrange Systems Technical Discussion
Betreff: Almost a year and a half ago, I did some work with SQL UDFs.
I'vesince forgotten some crucial things.

A year ago this past April, I was able, in my UDF experiments, to achieve
proof-of-concept on a UDF, based on an ILE RPG SRVPGM, to censor rows
returned in an SQL view.

And now, I've about forgotten most of what I did.

I was able to find the RPGLE source member for the proof-of-concept
censorship function. And I've found the docs on how to execute a CREATE
FUNCTION statement for an external UDF.

But any general advice on the subject would be appreciated.

As would the answer to a couple of specific questions:
(1) If I update the service program, do I then have to DROP the UDF and
CREATE it again?
(2) My censorship function's return value ("C" for censor, "P" for pass) is
derived from the parameters, and from the user profile under which the
function is executed. Can I assume that cached results of DETERMINISTIC
functions aren't shared across job boundaries? That this function that's
deterministic for any given user is DETERMINISTIC for SQL purposes?

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 ...


Return to Archive home page | Return to MIDRANGE.COM home page