The Rich Display does run the SQL statement on IBM i (which is what I assume you mean when you say "iSeries"). So in both cases, the SQL statement is running on the same computer by the same database engine.
The difference, I suspect, is the nature of the job that's running it. A standard Interactive or Batch job on IBM i knows the userid when it starts, and therefore the job name actually inclides that userid. Such as 123456/SKLEMENT/DSP01 (would be a job name for user named SKLEMENT). However, in a Rich Display, the job is submitted by the web server, and the job name is something like 123456/QTMHHTTP/PROFOUNDUI (so the user in the job name is the HTTP server's userid.) However, once Profound gets control it'll "synchronize" the userid to your Interactive job. So the userid changes in the middle of the job -- but the job id stays the same. So the jobid still says "QTMHHTTP" while the userid has actually switched to whatever your userid happens to be (PPBEDZ? or whatever it is.)
So that's the likely difference. In RPG programs, there are two spots in the PSDS, one that gets the user for the jobid, and one that gets the currently active user. So if this were an RPG program, I could easily tell you how to solve this, it'd just be a matter of using a different spot in the PSDS. But it's not, of course, it's an SQL statement.
For SQL, however, I had to do some research. It looks to me like the SESSION_USER is what you are looking for? So with your original idea, I would guess (and I don't really understand your original VIEW, so I could be wrong) that you could do this:
Code: Select all
create view audeptview as
SELECT DPWHID, DPDEPT , DPDPNM FROM wodpm inner join mcgaudet on
SESSION_USER = aduser and adtype = 'GLDPT' WHERE advalue = dpdept or
advalue = '*ALL'
Simply using SESSION_USER in place of USER, may do it? I don't know, because I really don't understand how that join works... (If it were in the WHERE clause, however, it'd make more sense to me.)
In your most recent post, however, you aren't using the JOIN anymore, so that makes things much easier. If it's okay to omit the join (and therefore, you don't need to use a VIEW anymore) then this should be pretty easy. You could just do
- 3-25-2015 7-13-23 PM.png (2.41 KiB) Viewed 461 times
If you wish to use our currentUser() API, that should also work. It's important to understand, however, that this isn't an SQL function. You can't call it directly in an SQL statement! What you would have to do is use a "parameter marker" (which is like a variable) in the statement, and fill-it in using the parameter value property.
So if you wanted to do that, you'd do this:
- 3-25-2015 7-17-36 PM.png (3.01 KiB) Viewed 461 times
The ? is a "parameter marker" (that's the SQL term for it) and can only take the place of a variable value. The "parameter value" property can be used to insert a value into the parameter marker at run time -- so in this case, I use "script:" to tell Profound UI to run some JavaScript code, and then I can call the currentUser() API to retrieve the current user. That current user will be inserted where the question mark (aka "parameter marker") is in the SQL statement.
So that's the other way to do it, here.. but I would think just using SESSION_USER would be simpler (assuming that it works for you... it worked fine in my tests.)