Monday, September 8, 2014

What is Access Level In Workflow ?

Oracle locks the workflow process/activities at certain access level to discourage customers altering critical parts of the flow and to preserve the customizations from patching. 
  • To modify such items, you will have to change your access level to lower than level already set.
  • However altering key parts of the workflow process is not recommended.

The access levels are defined as follows:
  •  0-9: Reserved for Oracle Workflow
  • 10-19: Reserved for Oracle Application Object Library
  • 20-99: Reserved for Oracle E-Business Suite
  • 100-999: Reserved for customer organizations
  • 1000: Public 
How does the developer define their Access Level?
Help-> About Oracle Workflow Builder 2.6.3 

Example- How Oracle protects their Objects from Modifications

Via help Menu, developer in Oracle Corporation will set Access Level to 20










Oracle developer locks the object at access level to 20













Developer at EBS Customer Site set the Access Level to 100















Access[100] is not between range 0 and 20. Hence Customer Site can not modify this activity

To modify such items, you will have to change your access level to lower than 20, so that it fits into the range of 0 to 20. However altering key parts of the workflow process is not recommended.

When Oracle developer unchecks “Lock at this access level”, then Protection becomes 1000

Access[100] is between range 0 and 1000. Hence Customer Site can modify this activity

However by checking Allow Modifications to customized object, Oracle will is able to modify the Customized  objects

Oracle delivers workflows via patches which use WFLOAD command to upload their definition to the Database

WFLOAD apps/password 0 Y <UPLOAD_MODE> XXXX.wft

Different “Upload Modes” applicable to WFLOAD
  • UPGRADE – Honours both protection and customization levels of data
  • UPLOAD -    Honours only protection level of data [No respect of Customization Level]
  • FORCE   -     Force upload regardless of protection or customization level
As a standard practice, Oracle’s upgrade patches mostly run in UPGRADE mode, hence customizations can protected.















Friday, September 5, 2014

SQL LOADER

SQL LOADER is an Oracle utility used to load data into table given a datafile which has the records that need to be loaded.

SQL*Loader takes data file, as well as a control file, to insert data into the table. When a Control file is executed, it can create Three (3) files called log file, bad file or reject file, discard file.
  • Log file tells you the state of the tables and indexes and the number of logical records already read from the input datafile. This information can be used to resume the load where it left off. 
  • Bad file or reject file gives you the records that were rejected because of formatting errors or because they caused Oracle errors.
  • Discard file specifies the records that do not meet any of the loading criteria like when any of the WHEN clauses specified in the control file. These records differ from rejected records.
Conventional and Direct path loader
  • The conventional path loader essentially loads the data by using standard INSERT statements. 
  • The direct path loader (DIRECT=TRUE) bypasses much of the logic involved with that, and loads directly into the Oracle data files.

Some of the restrictions with direct path loads are:

  • Loaded data will not be replicated
  • Cannot always use SQL strings for column processing in the control file (something like this will probably fail: col1 date "ddmonyyyy" "substr(:period,1,9)"). Details are in Metalink Note:230120.1. 

Structure of the data file:
The data file can be in fixed record format or variable record format.
Fixed Record Format would look like the below. In this case you give a specific position where the Control file can expect a data field:

1001       ARUN              CLERK                 1013     12/17/1980       800
1002       AMIT               SALESMAN         1006     2/20/1981         1600
1003       WARD             SALESMAN         1006     2/22/1981         1250
1004       JONY               MANAGER          1009     4/2/1981            2975
1005       MATT             SALESMAN         1006      9/28/1981         1250
1006       RAO                MANAGER           1009     5/1/1981            2850
1007       CADD             MANAGER           1009     6/9/1981            2450
1008       SUNITH          ANALYST            1004     12/9/1982          3000
1009       KING               PRESIDENT                      11/17/1981        5000
1010       GEORGE         SALESMAN         1006     9/8/1981            1500
1011       DAVI               CLERK                 1008     1/12/1983           1100
1012       JAMES            CLERK                 1006     12/3/1981           950
1013       FARUQ           ANALYST            1004     12/3/1981          3000
1014       MIKE              CLERK                  1007     1/23/1982          1300

Variable Record Format would like below where the data fields are separated by a delimiter.
Note: The Delimiter can be anything you like. In this case it is “|”

1196700|9|0|692.64
1378901|2|3900|488.62
1418700|2|2320|467.92
1418702|14|8740|4056.36
1499100|1|0|3.68
1632800|3|0|1866.66
1632900|1|70|12.64
1637600|50|0|755.5

Structure of a Control file:
Sample CTL file for loading a Variable record data file:

OPTIONS (SKIP = 1)                                 --The first row in the data file is skipped without loading
LOAD DATA
INFILE ‘$FILE’                                         -- Specify the data file  path and name
APPEND                                                    -- type of loading (INSERT, APPEND, REPLACE, TRUNCATE
INTO TABLE “APPS”.”BUDGET”         -- the table to be loaded into
FIELDS TERMINATED BY ‘|’                -- Specify the delimiter if variable format datafile
OPTIONALLY ENCLOSED BY ‘”‘        --the values of the data fields may be enclosed in “
TRAILING NULLCOLS                          --columns that are not present in the record treated as null
(ITEM_ID             “TRIM(:ITEM_ID)”,  -- Can use all SQL functions on columns
QTY                        DECIMAL EXTERNAL,
REVENUE             DECIMAL EXTERNAL,
EXT_COST            DECIMAL EXTERNAL TERMINATED BY WHITESPACE “(TRIM(:EXT_COST))”  ,
MONTH                “to_char(LAST_DAY(ADD_MONTHS(SYSDATE,-1)),’DD-MON-YY’)” ,
DIVISION_CODE       CONSTANT “AUD”  -- Can specify constant value instead of Getting value from datafile
)

OPTION statement precedes the LOAD DATA statement. The OPTIONS parameter allows you to specify runtime arguments in the control file, rather than on the command line. 

The following arguments can be specified using the OPTIONS parameter.

  • SKIP = n             -- Number of logical records to skip (Default 0)
  • LOAD = n          --Number of logical records to load (Default all)
  • ERRORS = n      --Number of errors to allow (Default 50)
  • ROWS = n  -      - Number of rows in conventional path bind array or between direct path data saves (Default: Conventional Path 64, Direct path all)
  • BINDSIZE = n   -- Size of conventional path bind array in bytes (System-dependent default)
  • SILENT = {FEEDBACK | ERRORS | DISCARDS | ALL} — Suppress messages during run (header, feedback, errors, discards, partitions, all)
  • DIRECT = {TRUE | FALSE} –Use direct path (Default FALSE)
  • PARALLEL = {TRUE | FALSE} — Perform parallel load (Default FALSE)  
LOAD DATA statement is required at the beginning of the control file.
INFILE: INFILE keyword is used to specify location of the datafile or datafiles.
INFILE* specifies that the data is found in the control file and not in an external file. INFILE
‘$FILE’, can be used to send the filepath and filename as a parameter when registered as a concurrent program.
INFILE   ‘/home/Ooracle/ad/import.csv’ specifies the filepath and the filename.

Example where datafile is an external file:

LOAD DATA
INFILE   ‘/home/Ooracle/ad/import.csv’
INTO TABLE emp_details
FIELDS TERMINATED BY “,”
( emp_num, emp_name, department_num, department_name )

Example where datafile is in the Control file:

LOAD DATA
INFILE *
INTO TABLE emp_details
FIELDS TERMINATED BY “,”
( emp_num, emp_name, department_num, department_name )
BEGINDATA
1001,ARUN,1013,Accounting
1002,AMIT,1006,Sales
1003,WARD,1006,Accounting
1004,JONY,1009,Sales
1005,MATT,1006,Accounting

Example where file name and path is sent as a parameter when registered as a concurrent program

LOAD DATA
INFILE ‘$FILE’
INTO TABLE emp_details
FIELDS TERMINATED BY “,”


( emp_num, emp_name, department_num, department_name )

TYPE OF LOADING:
  • INSERT   — If the table you are loading is empty, INSERT can be used.
  • APPEND  — If data already exists in the table, SQL*Loader appends the new rows to it. If data doesn’t already exist, the new rows are simply loaded. 
  • REPLACE — All rows in the table are deleted and the new data is loaded
  • TRUNCATE — SQL*Loader uses the SQL TRUNCATE command.



INTO TABLE is required to identify the table to be loaded into. In the above example INTO TABLE “APPS”.”BUDGET”
APPS refers to the Schema and BUDGET is the Table name.
FIELDS TERMINATED BY specifies how the data fields are terminated in the datafile.(If the file is Comma delimited or Pipe delimited etc)
OPTIONALLY ENCLOSED BY ‘”‘ specifies that data fields may also be enclosed by quotation marks.
TRAILINGNULLCOLS clause tells SQL*Loader to treat any relatively positioned columns that are not present in the record as null columns.

Loading a fixed format data file:
LOAD DATA
INFILE ‘sample.dat’
INTO TABLE emp
(     empno         POSITION(01:04)   INTEGER EXTERNAL,
      ename          POSITION(06:15)   CHAR,
      job               POSITION(17:25)   CHAR,
      mgr              POSITION(27:30)   INTEGER EXTERNAL,
      sal                POSITION(32:39)   DECIMAL EXTERNAL,
      comm           POSITION(41:48)   DECIMAL EXTERNAL,
      deptno          POSITION(50:51)   INTEGER EXTERNAL)

Steps to Run the SQL* LOADER from UNIX:
At the prompt, invoke SQL*Loader as follows: 

sqlldr USERID= scott/tiger CONTROL=  <control filename> LOG = <Log file name>

Register as concurrent Program:
  • Place the Control file in $CUSTOM_TOP/bin.
  • Define the Executable. Give the Execution Method as SQL*LOADER.
  • Define the Program. Add the Parameter for FILENAME.


Default path for Discard, bad and log files
If bad and discard file paths are not specified in the CTL file and if this SQL Loader is registered as a concurrent program, then they will be created in the directory where the regular Concurrent programs’ output files reside. You can also find the paths where the discard and bad files have been created in the log file of the SQL LOADER concurrent request.

Skip columns:
You can skip columns using the ‘FILLER’ option.
Load Data
--
--
TRAILING  NULLCOLS
(
name Filler,
Empno ,
sal
)

here the column name will be skipped.

Load a multiple files into single table:

SQL LOADER lets you load multiple data files at once into a single table. But all the data files should be of the same format. 

Here is a example:
Say you have a table named EMP which has the below structure: 
Column                Data Type
emp_num                 Number
emp_name         Varchar2(25)
department_num Number
department_name Varchar2(25)

You are trying to load the below comma delimited data files named eg.dat and eg1.dat:

eg.dat:
1001,ARUN,1013,Accounting
1002,AMIT,1006,Sales
1003,WARD,1006,Accounting
1004,JONY,1009,Sales
1005,MATT,1006,Accounting

eg1.dat:
1234,Tom,2345,Accounting
3456,Berry,8976,Accounting

The Control file should be built as below:

LOAD DATA
INFILE ‘eg.dat’    — File 1
INFILE ‘eg1.dat’  — File 2
APPEND
INTO TABLE emp
FIELDS TERMINATED BY “,”
( emp_num, emp_name, department_num, department_name )

Load a single file into multiple tables:

SQL Loader lets you load a single data file into multiple tables using “INTO TABLE” clause. 

Here is a example:
Say you have two tables named EMP and DEPT which have the below structure: 
Table Column                 Data Type
EMP emp_num                 Number
EMP emp_name         Varchar2(25)
DEPT department_num Number
DEPT department_name Varchar2(25)

You are trying to load the below comma delimited data file named eg.dat which has columns Emp_num and emp_name that need to be loaded into table EMP and columns department_num and department_name that need to be loaded into table DEPT using a single CTL file here.

eg.dat:
1001,ARUN,1013,Accounting
1002,AMIT,1006,Sales
1003,WARD,1006,Accounting
1004,JONY,1009,Sales
1005,MATT,1006,Accounting

The Control file should be built as below:

LOAD DATA
INFILE ‘eg.dat’
APPEND
INTO TABLE emp
FIELDS TERMINATED BY “,”
( emp_num, emp_name )
INTO TABLE dept
FIELDS TERMINATED BY “,”
(department_num, department_name)

You can further use WHEN clause to selectively load the records into the tables which will be explained later in this article.

 Skip a column while loading using “FILLER” and Load field in the delimited data file into two different columns in a table using “POSITION”
SQL LOADER also lets you load the same field into two different columns of the table. 

If the data file is position based, loading the same field into two different columns is pretty straight forward. You can use Position (start_pos:end_pos) keyword
If the data file is a delimited file and it has a header included in it, then this can be achieved by referring the field preceded with “:” eg description “(:emp_name)”.
If the data file is delimited file without a header included in it, Position (start_pos:end_pos) or “(:field)” will not work. This can be achieved using POSITION (1) clause which takes you to the beginning of the record. 

Example:
The requirement here is to load the field emp_name in the data field into two columns – emp_name and description of the table EMP.

Say you have a table named EMP which has the below structure: 
Column                Data Type
emp_num                Number
emp_name        Varchar2(25)
description        Varchar2(25)
department_num Number
department_name Varchar2(25)

You are trying to load the below comma delimited data file named eg.dat which has 4 fields that need to be loaded into 5 columns of the table EMP.

eg.dat:
1001,ARUN,1013,Accounting
1002,AMIT,1006,Sales
1003,WARD,1006,Accounting
1004,JONY,1009,Sales
1005,MATT,1006,Accounting

Control File:

LOAD DATA
INFILE ‘eg.dat’
APPEND
INTO TABLE emp
FIELDS TERMINATED BY “,”
(emp_num, 
emp_name, 
desc_skip FILLER POSITION(1),
description,
department_num, 
department_name)

Explanation on how SQL LOADER processes the above CTL file:
  • The first field in the data file is loaded into column emp_num of table EMP
  • The second field in the data file is loaded into column emp_name of table EMP
  • The field desc_skip enables SQL LOADER to start scanning the same record it is at from the beginning because of the clause POSITION(1) . SQL LOADER again reads the first delimited field and skips it as directed by “FILLER” keyword. 
  • Now SQL LOADER reads the second field again and loads it into description column of the table EMP.
  • SQL LOADER then reads the third field in the data file and loads into column department_num of table EMP
  • Finally the fourth field is loaded into column department_name of table EMP.


Usage of BOUNDFILLER 
BOUNDFILLER is available with Oracle 9i and above and can be used if the skipped column’s value will be required later again.

Example: 
The requirement is to load first two fields concatenated with the third field as emp_num into table emp and Fourth field as Emp_name 

Data File:
1,15,1001,ARUN
1,15,1002,AMIT
1,15,1003,WARD
1,18,1004,JONY
1,20,1005,MATT

The requirement can be achieved using the below Control File:

LOAD DATA
INFILE ‘C:\eg.dat’
APPEND
INTO TABLE EMP
FIELDS TERMINATED BY “,” 
(
Rec_skip BOUNDFILLER, 
tmp_skip BOUNDFILLER, 
Emp_num “(:Rec_skip||:tmp_skip||:emp_num)”,
Emp_name 
)

 Load the same record twice into a single table:

SQL Loader lets you load record twice using POSITION clause but you have to take into account whether the constraints defined on the table allow you to insert duplicate rows.

Below is the Control file:

LOAD DATA
INFILE ‘eg.dat’
APPEND
INTO TABLE emp
FIELDS TERMINATED BY “,”
( emp_num, emp_name, department_num, department_name )
INTO TABLE emp
FIELDS TERMINATED BY “,”
(emp_num POSITION(1),emp_name,department_num,department_name)

SQL LOADER processes the above control file this way:

  • First “INTO TABLE” clause loads the 4 fields specified in the first line of the data file into the respective columns (emp_num, emp_name, department_num, department_name)
  • Field scanning does not start over from the beginning of the record when SQL LOADER encounters the second INTO TABLE clause in the CTL file. Instead, scanning continues where it left off. Statement “emp_num POSITION(1)” in the CTL file forces the SQL LOADER to read the same record from the beginning and loads the first field in the data file into emp_num column again. 
  • The remaining fields in the first record of the data file are again loaded into respective columns emp_name, department_num, department_name. Thus the same record can be loaded multiple times into the same table using “INTO TABLE” clause.


Using WHEN to selectively load the records into the table

WHEN clause can be used to direct SQL LOADER to load the record only when the condition specified in the WHEN clause is TRUE. WHEN statement can have any number of comparisons preceded by AND. 
SQL*Loader does not allow the use of OR in the WHEN clause. 

Here is a example which illustrates how to load the records into 2 tables EMP and DEPT based on the record type specified in the data file
.
The below is delimited data file eg.dat which has the first field as the record type. The requirement here is to load all the records with record type = 1 into table EMP and all the records with record type = 2 into table DEPT and record with record type =3 which happens to be the trailer record should not be loaded. 

1,1001,ARUN
2,1013,Accounting
1,1002,AMIT
2,1006,Sales
1,1003,WARD
2,1006,Accounting
1,1004,JONY
2,1009,Sales
1,1005,MATT
2,1006,Accounting
3,10

Control File: 

LOAD DATA
INFILE ‘eg.dat’
APPEND
INTO TABLE emp
WHEN (01) = ’1′
FIELDS TERMINATED BY “,”
( rec_skip filler POSITION(1),emp_num , emp_name ) 
INTO TABLE dept
WHEN (01) = ’2′
FIELDS TERMINATED BY “,”
(rec_skip filler POSITION(1),department_num, 
department_name )

Let’s now see how SQL LOADER processes the CTL file:
  • SQL LOADER loads the records into table EMP only when first position (01) of the record which happens to be the record type is ’1′ as directed by command INTO TABLE emp WHEN (01) = ’1′
  • If condition When (01) = ’1′ holds true for the current record, then SQL LOADER gets to the beginning of the record as directed by command POSITION(1) and skips the first field which is the record type.
  • It then loads the second field into emp_num and third field into emp_name column in the table EMP.
  • SQL LOADER loads the records into table DEPT only when first position (01) of the record which happens to be the record type is ’2′ as directed by the commands - INTO TABLE dept WHEN (01) = ’2′
  • If condition When (01) = ’2′ holds true for the current record, then SQL LOADER gets to the beginning of the record as directed by command POSITION(1) and skips the first field which is the record type.
  • It then loads the second field into department_num and third field into department_name columns in the table DEPT.
  • The records with record type = ’3′ are not loaded into any table. 


Thus you can selectively loads the necessary records into various tables using WHEN clause.

Thursday, September 4, 2014

Multiple Organization Access Control (MOAC)


The single most major change in R12 is the introduction of a concept known as Multiple Organizations Access Control (MOAC). This is a new feature in the existing Multi-org architecture.
Previously, in 11i, data was restricted to a single operating unit using views which partition the base table data, based on the Operating Unit setting controlled by Profile Options.
  • Data from all the operating units are present in tables that are usually followed by a ‘_ALL’ in their name.
  • Each table contained a column called ORG_ID that represented which operating unit a particular row belonged to.
  • Data was then restricted using views (without _ALL) that returned data corresponding to the current organization’s ORG_ID.

This is replaced by a more flexible architecture in R12 that allows users to access data from more than one operating unit using a single responsibility. Defining security profiles does this.
  • Oracle Multi-org views have been removed, and replaced with synonyms.
  • The synonym points to the _ALL table.

Attaching a Virtual Private Database (VPD) policy to the synonym does the data restriction.

Features of 11.5.9

  • MO: Operating Unit profile option at responsibility level sets the Operating Unit context
  • FND Initialize client_info() to the value of MO: Operating Unit when a new session is started

Features of R12

Responsibility level profile options:
  • MO: Operating Unit
  • MO: Security Profile
  • MO: Default Operating Unit
  • Profile 'MO: Operating Unit' will restrict data access for a single Operating Unit
  • Profile 'MO: Security Profile' will ensure access to multiple operating units from single responsibility
  • The operating unit field in the form will automatically default to the value set in profile ‘MO: Default Operating Unit'


Multi-Org Initialize:
  • De-centralized from FND Initialization
  • Global Temporary Table initialized to content of MO: Security Profile

Example:


In pre Release 12, you would have had following methodology for PO_HEADERS_ALL
a. A table is created in PO Schema, named PO_HEADERS_ALL
b. A synonym named PO_HEADERS_ALL is created in APPS schema, referring
    to PO.PO_HEADERS_ALL
c. Create a view PO_HEADERS in APPS schema, as

SELECT  *
FROM po_headers_all
WHERE org_id = client_info

But now in R12, following will happen
a. A table is created in PO Schema, named PO_HEADERS_ALL
b. A synonym named PO_HEADERS_ALL is created in APPS schema, referring
    to PO.PO_HEADERS_ALL
c. Another synonym named PO_HEADERS is created in APPS, referring to
    PO_HEADERS_ALL
d. A Row Level security is applied to PO_HEADERS, using package
function MO_GLOBAL.ORG_SECURITY.
This can be double-checked by running SQL

SELECT * FROM all_policies
WHERE object_name='PO_HEADERS'

Purpose of MO_GLOBAL.ORG_SECURITY:
The purpose of Row-Level-Security is to hide certain data [based on some conditions]. The function implementing the security policy works in the following manner:

  • If the access mode is M (Multiple), then the policy predicate issues an EXISTS sub-query to a global temporary table. The table stores and manipulates data specific to a SESSION or TRANSACTION.
  • If the access_mode is S (Single), then a simple equality predicate is used for performance reasons, since it is cost effective in comparison to the temporary table.
  • An access mode A (All) is incorporated to bypass the security for functionality that needs full table access.
 
If the access mode is not set or is NULL, then a simple predicate that uses the CLIENT_INFO value for ORG_ID is used for the policy predicate to support backward compatibility.




MO_GLOBAL.Org_Security function:

FUNCTION org_security (obj_schema VARCHAR2
                       obj_name VARCHAR2)
RETURN VARCHAR2
IS
BEGIN  --
  -- Returns different predicates based on the access_mode
  -- The codes for access_mode are
  -- M - Multiple OU Access
  -- A - All OU Access
  -- S - Single OU Access
  -- Null - Backward Compatibility - CLIENT_INFO case
  --
 IF g_access_mode IS NOT NULL THEN
   IF g_access_mode = 'M' THEN
     RETURN 'EXISTS (SELECT 1
                       FROM mo_glob_org_access_tmp oa
                       WHERE oa.organization_id = org_id)';
   ELSIF g_access_mode = 'A' THEN -- for future use
     RETURN NULL;
   ELSIF g_access_mode = 'S' THEN
     RETURN 'org_id = sys_context (''multi_org2'',''current_org_id'')';
   END IF;
 ELSE
   RETURN 'org_id = substrb (userenv (''CLIENT_INFO''), 1,10)';
 END IF;   
END org_security;
 
The effect of this policy is that, whenever you access PO_HEADERS,
Oracle RLS will dynamically append WHERE CLAUSE similar to below
 
SELECT * FROM PO_HEADERS
WHERE EXISTS (SELECT 1
              FROM mo_glob_org_access_tmp oa
                 WHERE oa.organization_id = org_id)

Or is modified at runtime if the user’s access responsibility can access one Operating Unit with access control enabled for the module to:

SELECT * FROM PO_HEADERS
WHERE ORG_ID = sys_context ('multi_org2','current_org_id');

The following code templates are to be used in R12.

1. To ADD Row Level Security (RLS) POLICY TO CUSTOM OBJECTS
BEGIN
   DBMS_RLS.add_policy(object_schema        => 'apps',
                       object_name          => 'xx_ad',
                        policy_name          => 'org_sec',
                        function_schema      => 'apps',
                        policy_function      => 'MO_GLOBAL.ORG_SECURITY',
                        statement_types      => 'select, insert,update, delete',
                        update_check         => TRUE,
                        ENABLE               => TRUE,
                        static_policy        => FALSE,
                        policy_type          => DBMS_RLS.shared_context_sensitive
                       );
END;
2. R12 INITIALISATION

To initialize to multiple operating units with same Responsibility

BEGIN
FND_GLOBAL.APPS_INITIALIZE('user_id','resp_id','resp_appl_id');
mo_global.init('appl_shrt_name');
END;
Purpose of MO_GLOBAL.INIT :- It will check if new Multi Org Security Profile is set, to decide if new Security Profile method will be used. If the new MO security profile is set, then mo_global.init inserts one record, for each Organization in Org Hierarchy, in table mo_glob_org_access_tmp. This package procedure will be called as soon as you login or as soon as you switch responsibility. Just like FND_GLOBAL.INITIALIZE is called. To initialize to a single Operating Unit
BEGIN
MO_GLOBAL.SET_POLICY_CONTEXT('S','org_id');
END;
Purpose of MO_GLOBAL.SET_POLICY_CONTEXT :-

This procedure has two parameters

p_access_mode: Pass a value "S" in case you want your current session to work against Single ORG_ID
               Pass a value of "M" in case you want your current session to work against multiple ORG_ID's

p_org_id:  Only applicable if p_access_mode is passed value of "S"