Error encountered with VPD Policy in place

Question

Local Platform: Windows XP
SQL DEV Version: 1.0.0.15.57
Host: Solaris Oracle 10.2.0.2.0
The problem I am incurring is related to using a VPD Policy and trying to update data via the table editor. I have included my function, the add policy statements and everything needed to duplicate this on the EMP table.
I am able to update the tables with the VPD policy in place using both SQLPLUS and the pl/sql editor region within SQL Developer..
The only thing that would need changed is before the function is compiled the user that you will be using to login to the database needs to be set within the function.
create or replace function
vpd_test_function
-- Function must have the following parameters
(schema in varchar2, tab in varchar2)
-- Function will return a string that is used as a WHERE clause
return varchar2
as
v_user varchar2(100);
out_string varchar2(4000) default null;
begin
-- get session user
v_user := UPPER(nvl(v('APP_USER'),USER));
-- create where clause when user is authorized to see parts of the table
if (v_user = 'DB_USER') then
out_string := out_string || '(nvl(deptno,0) <>10 and nvl(deptno,0) <>30)';
end if;
return out_string;
end;
begin
DBMS_RLS.add_policy
(object_schema => 'DB_USER',
object_name => 'EMP',
policy_name => 'VPD_TEST_POLICY',
function_schema => 'DB_USER',
policy_function => 'vpd_TEST_FUNCTION',
statement_types => 'SELECT,INSERT,UPDATE,DELETE');
end;
SELECT * FROM USER_POLICIES;
OBJECT_NAME POLICY_GROUP POLICY_NAME PF_OWNER PACKAGE FUNCTION SEL INS UPD DEL IDX CHK_OPTION ENABLE STATIC_POLICY POLICY_TYPE LONG_PREDICATE
EMP SYS_DEFAULT VPD_TEST_POLICY DB_USER VPD_TEST_FUNCTION YES YES YES YES NO NO YES NO DYNAMIC NO
1 rows selected
Change empno 7788 salary from 3000 to 85 results by clicking on a table and editing the value and clicking commit
UPDATE "DB_USER"."EMP" SET SAL = "85" WHERE ROWID = 'AAAXLmAAGAAAAylAAF' AND ORA_ROWSCN = '7788'
One error saving changes to table "DB_USER"."EMP":
Row 3: ORA-00904: "ORA_ROWSCN": invalid identifier
When run as a script or execute statement in SQL Developer (it works):
UPDATE EMP SET SAL = 85 WHERE EMPNO = 7788;
1 rows updated
Change policy by first dropping and then recreating, selecting to only apply the policy to select statements rather than INS,DEL,SEL,UPD:
BEGIN
DBMS_RLS.DROP_POLICY (
object_schema => 'DB_USER',
object_name => 'EMP',
policy_name => 'VPD_TEST_POLICY');
end;
begin
DBMS_RLS.add_policy
(object_schema => 'DB_USER',
object_name => 'EMP',
policy_name => 'VPD_TEST_POLICY',
function_schema => 'DB_USER',
policy_function => 'vpd_TEST_FUNCTION',
statement_types => 'SELECT');
end;
SELECT * FROM USER_POLICIES;
OBJECT_NAME POLICY_GROUP POLICY_NAME PF_OWNER PACKAGE FUNCTION SEL INS UPD DEL IDX CHK_OPTION ENABLE STATIC_POLICY POLICY_TYPE LONG_PREDICATE
EMP SYS_DEFAULT VPD_TEST_POLICY DB_USER VPD_TEST_FUNCTION YES NO NO NO NO NO YES NO DYNAMIC NO
1 rows selected
Change empno 7788 salary from 3000 to 85 results by clicking on a table and editing the value and clicking commit
One error saving changes to table "DB_USER"."EMP":
Row 3: Data updated by another user, cannot update row.
The following popup is displayed as well....
But once again when run as a script or execute statement in SQL Developer (it works):
UPDATE EMP SET SAL = 85 WHERE EMPNO = 7788;
1 rows updated
The last thing I would like to add is that if I drop the policy and I edit the table it works just fine ..
UPDATE "DB_USER"."EMP" SET SAL = "85" WHERE ROWID = 'AAAXLmAAGAAAAylAAF' AND ORA_ROWSCN = '57937995'
Commit Successful
The only twist is that if you notice when I have the VPD policy in place SQL Developer is aying that the ORA_ROWSCN is equal to EMPNO/the primary key and not the try ORA_ROWSCN...
Any ideas, I can file a TAR as well if you would like me to?
Thanks
Justin

Answer 1

I first identified the problem setting up VPD for a DB user, I granted them update privileges and I wanted to ensure everything was working and that is how I found it. So yes I logged into the DB as the "other user" and then went to "Other Users" and went to the table that was owned by another schema with a VPD policy when I first encounter the error.
It was when I setup the test case to post here on OTN that I discovered the error ALSO exists if I own the table as well so for me in my test cases it did not matter who the original owner of the table was. The only thing that mattered was whether or not a VPD policy was enabled on a table.