RE: Almost a year and a half ago, I did some work with SQL UDFs.

(1) If I update the service program, do I then have to DROP the UDF and
CREATE it again?

I believe you can recompile your service program as long as any parameter signatures don't change.

Regards,
Richard Schoen
RJS Software Systems Inc.
Where Information Meets Innovation
Document Management, Workflow, Report Delivery, Forms and Business Intelligence
Email: richard@xxxxxxxxxxxxxxx
Web Site: http://www.rjssoftware.com
Tel: (952) 736-5800
Fax: (952) 736-5801
Toll Free: (888) RJSSOFT


-----Original Message-----


message: 7
date: Wed, 05 Sep 2012 14:28:29 -0700
from: James Lampert <jamesl@xxxxxxxxxxxxxxxxx>
subject: Almost a year and a half ago, I did some work with SQL UDFs.
I've since 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?

--
JHHL