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

Welcome to 1990!

You need to use "Current User" @ 358-367 instead of "Job User" @ 254-263...

You could pass the user ID from the view itself via the USER,
SYSTEM_USER or SESSION_USER special registers depending on your exact
needs....

Note that that will give you the actual user profile, not the number
associated with it.

Charles

On Thu, Sep 6, 2012 at 2:33 PM, James Lampert <jamesl@xxxxxxxxxxxxxxxxx> wrote:

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