Oracle applications, fnd_standard.set_who

 

One of the best features of Oracle applications is the flexibility to add custom applications and extend the functionality of the business suite. Many time developers who are not well versed with the Oracle’s guidelines for custom development for Oracle applications will totally ignore the pre-requisites for fnd_standard.set_who API to work properly by avoiding to include the following mandatory columns while designing tables

  1. CREATION_DATE    DATE
  2. CREATED_BY    NUMBER
  3. LAST_UPDATE_DATE    DATE
  4. LAST_UPDATED_BY    NUMBER
  5. LAST_UPDATE_LOGIN    NUMBER

Which will fail the API call and result in “No record history available here” notification

Another possibility is, developer adds these columns with the custom tables at later stages and manually add the columns to the block, without involving the datablock wizard, thus not properly linking the block with newly created columns.

Manually adding the columns with proper column names and data types may not generate an error while compiling, however the API will not able to see those columns.

The best method to avoid this problem is, by running the data block wizard once after new columns are added to the custom table(s)

Run the data block wizard, refresh the data source and make sure you don’t have any column within the left side pan

Recompile and test the custom application once again. 99% this method should solve the fnd_standard.set_who API not updating information.

 

regards,

admin

Oracle E-Business Suite R12 Rapid forms development using Developer 6i forms

 

Moving from client server architecture to R12 based domains could be quite challenging for Oracle developers, especially those who have spent years, enjoying the flexibility of testing forms modules from the local development machines prior moving the “working” modules to the production instances.

Let us see the general development scenario for R12 instances.

  1. From 10g forms, connect to database
  2. open TEMPLATE.fmb and save as “XXMYFORM” etc
  3. Then keep on adding the elements

Now, move the form module to $AU_TOP/forms/US and compile it to respective application repositories

Create form, menu items…

A long list and the most frustrating is keeping on FTP the slightly modified forms module to the R12 instance to compile and testing.

We have came across a quick resolution for this PIA(Pain in the ASS) approach (for forms modules which do not use folder views) by using developer 6i (Uhu, beware Oracle fan boys would tell you, Oracle does not support developer 6i any further)

Create a template.fmb using Developer 6i forms

Change the system coordinates to use inches in the place of points

image

  1. Save the template.fmb
  2. Using save as, save your template.fmb as a new fmb file (eg: aa.fmb)
  3. Connect to apps database instance and start adding windows, canvases, blocks etc to the form and TEST IT locally!!!
  4. TEST it until the results are as expected.
  5. Make a backup for your working module (copy aa.fmb to bb.fmb for example)

 

Open your aa.fmb file, developed using forms 6i with Developer suite 10g forms designer (You will get prompts stating the possible conversions for triggers, coding etc)

Open TEMPLATE.fmb and save it as “MYAPPSFORM.fmb”

Now, please give maximum attention towards copying the objects from your 6i module which is opened with Developer 10g forms, TO your form module which will go to apps instance

  1. Copy all the windows you have created with 6i module to 10g forms
  2. Copy all the canvases you have created with 6i module to 10g forms
  3. Copy all the blocks you have created with 6i module to 10g forms
  4. Copy record groups, lovs, form level triggers if any

Now, try to compile the 10g form. If you have copied everything from 6i, this new form shouldn’t give you any compilation errors.

Move the form to apps instance, compile, create forms, menus and do final testing, confirming everything is working fine.

regards,

admin