我不使用APEX，但如果它以您自己（私人帐户）而不是普通应用帐户的身份登录，并且这是您所指的用户，那么无论您的客户端应用程序环境是什么，在SQL或PL/SQL中的数据库本身中，您始终可以使用变量USER来获取当前登录用户的身份。所以：

SELECT ..
 WHERE requester = USER

应该对你有用还提供了几个“USERENV”选项：

SELECT ..
 WHERE requester = SYS_CONTEXT('USERENV','AUTHENTICATED_IDENTITY') -- account used to connect to the database (can be different if proxy is used)

SELECT ..
 WHERE requester = SYS_CONTEXT('USERENV','CURRENT_SCHEMA') -- default schema if objects are not fully qualified. Can be changed by ALTER SESSION SET CURRENT_SCHEMA

SELECT ..
 WHERE requester = SYS_CONTEXT('USERENV','CURRENT_USER') -- user whose privs are active. In stored procs can be the procedure owner (not the session executing it) if AUTHID is at its default of DEFINER.

在任何顶点会话中，当前用户的值存储在绑定变量APP_USER中。在sql/plsql中，可以使用语法:APP_USER将此变量作为绑定变量访问。请注意，在您的示例中，“：”和“APP_USER”之间没有空格。
如果你想访问一个对象（view/package/trigger/...）中的变量，那么绑定变量不是一个选项。在该原因中，sys_context变量SYS_CONTEXT('APEX$SESSION', 'APP_USER')或旧的“V”函数（V('APP_USER')）
都记录在这里
现在来回答你的问题 * 我能做些什么来解决这个问题？*. Well... debug.使用源创建报告

SELECT requester, :APP_USER from "TaskAssignment"

并检查输出。也许情况不匹配，你需要在方程的一边做上/下来解决这个问题？这取决于你。它是你的数据，你的数据库，由你来修复;）
--更新--
查看报告输出，看起来“demandeur”列具有混合的案例数据。我想这就是问题所在。将where子句更改为：

UPPER(demandeur) = UPPER(:APP_USER)