FND_PROFILETo manipulate values stored in client and server user profile caches.Any changes you make to profile option values using these routines affect only the run-time environment. The effect of these settings end when the program ends, because the database session (which holds the profile cache) is terminated.
fnd_profile.VALUE(‘PROFILEOPTION’)
fnd_profile.VALUE(‘MFG_ORGANIZATION_ID’)
fnd_profile.VALUE(‘ORG_ID’)
fnd_profile.VALUE(‘LOGIN_ID’)
fnd_profile.VALUE(‘USER_ID’)
fnd_profile.VALUE(‘USERNAME’)
fnd_profile.VALUE(‘CONCURRENT_REQUEST_ID’)
fnd_profile.VALUE(‘GL_SET_OF_BKS_ID’)
fnd_profile.VALUE(‘SO_ORGANIZATION_ID’)
fnd_profile.VALUE(‘APPL_SHRT_NAME’)
fnd_profile.VALUE(‘RESP_NAME’)
fnd_profile.VALUE(‘RESP_ID’)
fnd_profile.VALUE(‘PER_BUSINESS_GROUP_ID’)
fnd_profile.VALUE(‘GL_SET_OF_BKS_ID’)
fnd_profile.VALUE(‘CURRENT_ORG_CONTEXT’)
FND_GLOBAL
The server-side package FND_GLOBAL returns the values of system globals, such as the login/signon or “session” type of values. You should not use FND_GLOBAL routines in your forms (that is on the client side). On the client side, most of the procedures in the FND_GLOBAL package are replaced by a user profile option with the same (or a similar) name. You should use FND_PROFILE routines in your forms instead.
fnd_global.USER_ID
fnd_global.USER_NAME
fnd_global.RESP_ID
fnd_global.RESP_NAME
fnd_global.APPLICATION_NAME
fnd_global.APPLICATION_SHORT_NAME
fnd_global.RESP_APPL_ID
fnd_global.BASE_LANGUAGE
fnd_global.CONC_LOGIN_ID
fnd_global.CONC_PRIORITY_REQUEST
fnd_global.CONC_PROCESS_ID
fnd_global.CONC_PROGRAM_ID
fnd_global.CONC_QUEUE_ID
fnd_global.CONC_REQUEST_ID
fnd_global.CURRENT_LANGUAGE
fnd_global.CUSTOMER_ID
fnd_global.EMPLOYEE_ID
fnd_global.FORM_APPL_ID
fnd_global.FORM_ID
fnd_global.GET_SESSION_CONTEXT
fnd_global.LANGUAGE_COUNT
fnd_global.LOGIN_ID
fnd_global.NEWLINE
fnd_global.NLS_DATE_FORMAT
fnd_global.NLS_DATE_LANGUAGE
fnd_global.NLS_LANGUAGE
fnd_global.NLS_NUMERIC_CHARACTERS
fnd_global.NLS_SORT
fnd_global.NLS_TERRITORY
fnd_global.ORG_ID
fnd_global.ORG_NAME
fnd_global.PARTY_ID
fnd_global.PER_BUSINESS_GROUP_ID
fnd_global.PER_SECURITY_PROFILE_ID
fnd_global.PROG_APPL_ID
fnd_global.QUEUE_APPL_ID
fnd_global.RT_TEST_ID
fnd_global.SECURITY_GROUP_ID
fnd_global.SERVER_ID
fnd_global.SESSION_ID
fnd_global.SUPPLIER_ID
fnd_global.TAB
Where do we use FND_GLOBAL and FND_PROFILE?
We can use them any where in PL/SQL to get values dynamically as per the session. In Forms we can use only FND_GLOBAL not FND_PROFILE.
Initializing the Environment
l_user_id := fnd_global.user_id;
l_resp_id := fnd_global.resp_id;
l_resp_appl_id := fnd_global.resp_appl_id;fnd_global.APPS_INITIALIZE(l_user_id,l_resp_id, l_resp_appl_id);
and this the difference between FND_GLOBAL and FND_PROFILE:
Though FND_GLOBAL and FND_PROFILE gives us same result but they work in a different fashion
FND_GLOBAL is a server-side package which returns the values of system globals, such as the login/signon or “session” type of values. Where as FND_PROFILE uses user profile routines to manipulate the option values stored in client and server user profile caches.
From this we can understand that FND_GLOBAL works on server side and FND_PROFILE works on client side.
On the client, a single user profile cache is shared by multiple form sessions. Thus, when Form A and Form B are both running on a single client, any changes Form A makes to the client’s user profile cache affect Form B’s run-time environment, and vice versa.
On the server, each form session has its own user profile cache. Thus, even if Form A and Form B are running on the same client, they have separate server profile caches. Server profile values changed from Form A’s session do not affect Form B’s session, and vice versa.
That is the reason in forms we use FND_GLOBAL.
