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

Oh, boy, I just discovered some trouble.

As it turns out, I still have a censored view from my previous experiments.

The censorship, based on current signed-on user (as derived from the PGSDS)

D SDS D LIB 81 90 D DUSER 254 263

works perfectly if I open the view with QuestView, or if I open the view with STRSQL.

But if I look at the view from Squirrel SQL, through a JDBC connection, the censorship doesn't work: I see records I'm not supposed to.

I see a QZDASOINIT job with these attributes (I've censored references to my own user profile):

Display Job Status Attributes
Job: QZDASOINIT User: QUSER Number: 031575 Status of job . . . . . . . . . . . . . . . : ACTIVE Current user profile . . . . . . . . . . . : <my-user-profile>
Job user identity . . . . . . . . . . . . . : <my-user-profile>
Set by . . . . . . . . . . . . . . . . . : *DEFAULT

I get the feeling that the PGSDS of my service program is returning QUSER instead of my own user profile (with which I established the JDBC connection).

How do I get around that, so the censorship function acts on the correct user profile?

And I suppose this kills DETERMINISTIC, since the JDBC runs in a prestart job. Or is there a way that the call to the UDF

WHERE CENSORACCT(U01430, U01429) = 'P'

in the view definition itself can pass (as somebody else suggested) the user ID?

(And note, U01430 and U01429 are not user profile names; they're numbers associated with user profiles).

--
JHHL