How to change a LOV query from Forms Personalization??
This is one of the requrirement that we want to add a additional condition to the LOV query or you want to populate the LOV all together from your SQL.
Its a simple four step process
Step1:
Get the Query that of the LOV of the standard form. You can do it by opening the standard form in the form builder or Get the query by taking the trace of the form and getting the query from the trace..
Step2:
If you want to add only a few more conditions to the query just add the conditions
In other case create a view with column same as in the standard query.
Step3:
In this step on when new form instance we will create the record Group from query
Step4:
Attach the record group to the LOV you want to change…
Step1:Get the query
The standard query is
select event_name, description from fa_maint_schedule_dtl WHERE EVENT_NAME LIKE :1
I want to populate from my own sql so I create a view
create or replace view XX_AMC_EVENT_DETAILS as
select 'SERVICE' EVENT_name ,'ATM SERVICE' DESCRIPTION from dual
union
select 'AMC' ,'AMC CONTRACT' from dual
union
select 'TEST1' ,'TEST2' from dual
Step2:
Plz find teh screen shots attached..
Friday, May 8, 2009
Tuesday, May 5, 2009
Terminating Concurrent program sessions
Hi ALL,
One way of finding the session id for concurrent is through fnd_cocurrent_request...as discussed in my earlier post
But there is another easy way...
select sid,serial#,MODULE,ACTION,status from V$session
the module will contain the concurrent program short name...If only one instance of the concurrent program is running
we can easily identify the sessions of it..
If we terminate the program and the session not got released..simply find th session
and use the command
alter sytem kill session 'SID,SERIAL#'
Please the values you got from the above query
One way of finding the session id for concurrent is through fnd_cocurrent_request...as discussed in my earlier post
But there is another easy way...
select sid,serial#,MODULE,ACTION,status from V$session
the module will contain the concurrent program short name...If only one instance of the concurrent program is running
we can easily identify the sessions of it..
If we terminate the program and the session not got released..simply find th session
and use the command
alter sytem kill session 'SID,SERIAL#'
Please the values you got from the above query
7 Ways for a Better LOG--My View..Suggestions Welcomed
Hi All,
we all use the log files for debugging issues by writting text into them when ever a exception occurs or to know the process flow of our code...Here are few steps that will make us to have better log and make our life easy during supporting phase..
7 ways for writing a Better Log
1.Always Display the Name of the package/procedure in the LOG File.
The main advantage of doing this is no need query the concurrent program name and executable to find the procedure of
concurrent program
2.It is always better to have a common package having the log function.So that every time we want to write into a log
there is no need to type entire fnd_file.put_line(fnd_file.log,'message'
it can be easily done like
xxab_util_pkg.log('message');
it is better to have out also in the same way...
3.If the code is running very long number of lines define a stage variables and set it at different levels..and the dispaly the stage completed value when ever the exception occurs...This helps to debug the issue faster...
4.Display all the derived values in the log
5.When ever you are displaying statements like no data found for any sqlstatments in the code display all the values passed to the SQL along with nodatafound or too many row exception.This inturn will reduce a lot of time during support...
6.Always make sure you attach the SQLERRM variable with the when other exceptions handled...and diplay the section name which is causing this exception
exception
when others then
fnd_File.put_line('Unhandled exception occured in XX_GL_INTF_PKG.Check_PERIOD:'||SQLERRM);
7.Always End the concurrent program either in ERROR or warning when ever a exception occurs in the programs unless it is a business requirement.
we all use the log files for debugging issues by writting text into them when ever a exception occurs or to know the process flow of our code...Here are few steps that will make us to have better log and make our life easy during supporting phase..
7 ways for writing a Better Log
1.Always Display the Name of the package/procedure in the LOG File.
The main advantage of doing this is no need query the concurrent program name and executable to find the procedure of
concurrent program
2.It is always better to have a common package having the log function.So that every time we want to write into a log
there is no need to type entire fnd_file.put_line(fnd_file.log,'message'
it can be easily done like
xxab_util_pkg.log('message');
it is better to have out also in the same way...
3.If the code is running very long number of lines define a stage variables and set it at different levels..and the dispaly the stage completed value when ever the exception occurs...This helps to debug the issue faster...
4.Display all the derived values in the log
5.When ever you are displaying statements like no data found for any sqlstatments in the code display all the values passed to the SQL along with nodatafound or too many row exception.This inturn will reduce a lot of time during support...
6.Always make sure you attach the SQLERRM variable with the when other exceptions handled...and diplay the section name which is causing this exception
exception
when others then
fnd_File.put_line('Unhandled exception occured in XX_GL_INTF_PKG.Check_PERIOD:'||SQLERRM);
7.Always End the concurrent program either in ERROR or warning when ever a exception occurs in the programs unless it is a business requirement.
Subscribe to:
Posts (Atom)