SOLUTION for FRM-18108: Failed to load the following objects.
ERROR
FRM-18108: Failed to load the following objects.
Source Module: APPSTAND Source Object: STANDARD_PC_AND_VA
Source Module: APPSTAND Source Object: STANDARD_TOOLBAR
Source Module: APPSTAND Source Object: STANDARD_CALENDAR
SOLUTION:
- Copy the Form file(.fmb) APPSTAND.fmb from $AU_TOP(appl_top/au/forms/US)
- And Paste into your Local forms folder(mentioned inFORMS_PATH)
- Open the Form Builder, First open that APPSTAND.fmb Form , Now You try to Open the form.
- FRM-18108: Error will not come.

Adding new user in Oracle Apps (EBS) from back end


Application users in Oracle Apps (EBS) can be created from the front end as well as back end. The back end method for user creation can be used when you don’t have sysadmin access to the application or also it can be used to speed up the process when there are many userids to be created.

You will require apps access to connect to database  to run the package fnd_user_pkg.


We can create user, disable/enable user, add/delete responsibility to the user through back end using this seeded oracle API.


fnd_user_pkg is the seeded API provided by Oracle.

In this post we will see how to use below two functionality of this API
Step 1: createuser : the procedure to create the user
Step 2: addresp : the procedure to add responsibility to a user

Step 1: createuser : - fnd_user_pkg.createuser

DECLARE
v_user_name VARCHAR2 (100) := upper('&Enter_User_Name');
 v_description VARCHAR2 (100) := 'NEW Test User';
BEGIN
 fnd_user_pkg.createuser
(x_user_name => v_user_name,
 x_owner => NULL,
 x_unencrypted_password => '&input_password',
 x_session_number => 0,
 x_start_date => SYSDATE,
 x_end_date => NULL,
 x_last_logon_date => NULL,
 x_description => v_description,
 x_password_date => NULL,
 x_password_accesses_left => NULL,
 x_password_lifespan_accesses => NULL,
 x_password_lifespan_days => NULL,
 x_employee_id => NULL,
 x_email_address => NULL,
 x_fax => NULL,
 x_customer_id => NULL,
 x_supplier_id => NULL,
 x_user_guid => NULL,
 x_change_source => NULL
 );
 COMMIT;
END;

Step 2: Simple anonymous block to add responsibility(Sysadmin) to the user :


BEGIN
fnd_user_pkg.addresp ('&Enter_User_Name','SYSADMIN',

'SYSTEM_ADMINISTRATOR','STANDARD',
'Add Responsibility to USER using pl/sql',SYSDATE,SYSDATE + 100);
commit;
dbms_output.put_line('Responsibility Added Successfully');
exception
        WHEN others THEN
                dbms_output.put_line(' Responsibility is not added due to ' || SQLCODE || substr(SQLERRM, 1, 100));
                ROLLBACK;
END;



FNDLOAD: command not found


Normally we use FNDLOADS to download and upload the ldts of program files for example concurrent program and request groups …

While uploading or downloading FNDLOADS we may get following error

FNDLOAD: command not found:

Oracle apps learning


Solution: Apply. Env file as shown below 


Oracle apps learning 


 After apply .env file the error will be resoled FNDLOAD: command not found issue 


Oracle apps learning 



Materialized View in Sql Oracle

Materialized view in SQL is also a logical structure which is stored physically on the disc. Like a view in Materialized views in SQL we are using simple select statement to create it.You should have create materialized views privileges to create a Materialized views. Definition of Materialized views (called as MV) has been stored in databases. Materialized views are useful in Data-warehousing concepts. When you create a Materialized view, Oracle Database creates one internal table and at least one index, and may create one view, all in the schema of the materialized views. Oracle Database uses these objects to maintain the materialized views in SQL data. You must have the privileges necessary to create these objects.

  • Materialized view in SQL Syntax and Examples:

“Materialized views are also known as snapshots..”
Snapshots acts like a physical table because data from snapshots are storing in to physical memory. Snapshot retrieves data very fast. So for performance tuning Snapshots are used. Following is the syntax of materialized view:

Create materialized view View_Name

Build [Immediate/Deffered]

Refresh [Fast/Complete/Force]

on [Commit/Demand]

as Select ..........;

Using above syntax you can create materialized views. The Syntax includes some different optional fields:
1.Build Immediate: Means materialized views(mv) created immediately.
2.Build Deffered:Means materialized views(mv) created after one refresh.
3.Refresh on commit:
This option committed the data in materialized views in SQL immediately after data inserted and committed in table.This option is known as incremental refresh option.View is not fully refreshed with this option
4.Refresh on Demand:
Using this option you can add the condition for refreshing data in materialized views.

You can refresh the data using fast (incremental approach),Complete,Force options.
Example:
CREATE MATERIALIZED VIEW MV_Employee BUILD immediate
REFRESH complete
on commit SELECT * FROM Employee;

Materialized View Real Life Example:

Materialized Views are basically used in the scenarios where actual performance tuning for query is needed.Materialized views are used mostly in reports where user wants to fetch the records very fast.I will try to explain the real life scenario where exactly materialized view is useful.When user creates materialized view then one table structure is created and user directly fetches that data from that table structure.
Suppose there are 2 tables named Employee and Department. The Employee table contains 1 million records and department table contains 20 records.We need to fetch the Employees associated with that department.
Step 1:
To Perform above scenario we basically create view:
Create View V_Employee
as
Select E.Employee_num,E.Employee_name,D.Department_Name
from Employee E , Department D where E.Dept_no=D.Dept_no;
Step 2:
Fetch the records from the View
Select * from V_Employee;
It will fetch 10 million records with associated department.But to fetch that records check the time.Let us consider it will take 2 Mins means 120 secs to fetch records
Step 3 :
Let us Create materialized view which will refresh automatically.
Create or Replace Materialized view MV_Employee
as
Select E.Employee_num,E.Employee_name,D.Department_Name
from Employee E , Department D where E.Dept_no=D.Dept_no
Refresh auto on commit select * from Department;
We have created materialized views in sql for that.and lets check performance.
Select* from MV_Employee;
It will fetch 1 million records in 60 secs.So performance is improved double when you use materialized view.

Materialized view log:

What is Incremental or Fast Refresh?

When in database level some DML changes are done then Oracle Database stores rows describing those changes in the materialized view log and then uses the materialized view log to refresh materialized views based on the master table. This process is called incremental or fast refresh. 
In this situation materialized view is not full refresh and it only refresh the data on incremental basic and only incremental data is added in to materialized view.

What is Complete Refresh?

Without a materialized views log, Oracle Database must re-execute the materialized view query to refresh the materialized views. This process is called a complete refresh. Usually, a fast refresh takes less time than a complete refresh.A materialized views log is located in the master database in the same schema as the master table. A master table can have only one materialized view’s log defined on it. Oracle Database can use this materialized view log to perform fast refreshes for all fast-refreshable materialized views based on the master table.To fast refresh a materialized join view, you must create a materialized view log for each of the tables referenced by the materialized views.

Hope you will get actual idea about materialized views in SQL.If you like this article do not forget to comment here.

What is difference between View and Materialized View


What is View in database
Views are a logical virtual table created by “select query” but the result is not stored anywhere in the disk and every time we need to fire the query when we need data, so always we get updated or latest data from original tables.

Performance of the view depends on our select query. If we want to improve the performance of view we should avoid using join statement in our query or if we need multiple joins between table always try to use the index based column for joining as we know index based columns are faster than a non-index based column.

View also allows storing the definition of the query in the database itself.




What is Materialized View in database
Materialized views are also the logical view of our data-driven by the select query but the result of the query will get stored in the table or disk, also the definition of the query will also store in the database.

When we see the performance of Materialized view it is better than normal View because the data of materialized view will be stored in table and table may be 
indexed so faster for joining also joining is done at the time of materialized views refresh time so no need to every time fire join statement as in case of view.



Difference between View vs Materialized View in database
Based upon on our understanding of View and Materialized View, Let’s see, some short difference between them :

1) The first difference between View and materialized view is that In Views query result is not stored in the disk or database but Materialized view allow to store the query result in disk or table.

2) 
This is continuation of first difference between View and Materialized View, In case of view its only the logical view of table no separate copy of table but in case of Materialized view we get physically separate copy of table

3) One more difference between View and materialized view in the database is that In case of View we always get latest data but in case of Materialized view we need to refresh the view for getting latest data.

4) Performance of View is less than Materialized view.

5) Another difference between View vs materialized view is that, when we create a view using any table, rowid of view is same as the original table but in case of Materialized view rowid is different. 

6) Last difference between View vs Materialized View is that In case of Materialized view we need an extra trigger or some automatic method so that we can keep MV refreshed, this is not required for views in the database.

Oracle Report Triggers

There are eight report triggers. Of these, there are five global triggers called the Report Triggers. They are fired in the following order :
* Before Parameter Form
* After Parameter Form
* Before Report
* Between Pages
* After Report

Apart from the above Five Report Triggers, there are three other types of triggers :
* Validation Triggers
* Format Triggers
* Action Triggers

Before Form: Fires before the run-time Parameter Form is displayed. From this trigger, you can access and change the values of parameters, PL/SQL global variables, and report-level columns. 

After Form: Fires after the run-time Parameter Form is displayed. From this trigger, you can access parameters and check their values. This trigger can also be used to change parameter values or, if an error occurs, return to the run-time Parameter Form. Columns from the data model are not accessible from this trigger. 

Before Report: Fires before the report is executed but after queries are parsed and data is fetched.

Between Pages: Fires before each page of the report is formatted, except the very first page. This trigger can be used for customized page formatting. 

After Report: Fires after you exit the Previewer, or after report output is sent to a specified destination, such as a file, a printer. This trigger can be used to clean up any initial processing that was done, such as deleting tables. 

Validation Triggers: Validation Triggers are PL/SQL functions that are executed when parameter values are specified on the command line and when you accept the run-time Parameter Form. Validation Triggers are also used to validate the Initial Value of the parameter in the Parameter property sheet.

Format Triggers: Format Triggers are PL/SQL functions executed before the object is formatted. The trigger can be used to dynamically change the formatting attributes of the object.

Action Triggers: Action Triggers are PL/SQL procedures executed when a button is selected in the Previewer. The trigger can be used to dynamically call another report (drill down) or execute any other PL/SQL.