ORACLE APPLICATIONS ARCHIVES

Topicwise collection of
Postings on Mail Lists
ON
ORACLE APPLICATION FORMS



Conversion(Forms3.0)to Forms4.5

Date: Fri, 19 Mar 1999 15:26:48 PST
From: "Anil Kumar"

Hi Patel,

Yeah, u can get s/w which can convert Forms3 2 Forms4.5; one is from Kumaran Systems(a href="../change/kumaran.htm"target="_new">www.kumaran.com) & the other in Seirra Optima Ltd. (a href="../change/sierraopt.htm"target="_new">www.sierraopt.com); try it out; bye, -AK


Hi all,

Does anyone know what precautions should we take when we convert forms3.0 to forms4.5.
Any useful tips,suggestions are greatly appreciated.
If I want to load forms3.0 & unix(sco) into my PC, where do I get the softwares? Thanks in advance.


Date: Mon, 22 Mar 1999 11:15:25 -0500
From: "Yadav, Surendra S."
Subject: RE: Conversion(Forms3.0)to Forms4.5

The following is an Oracle white paper on Forms conversion. I'm not sure what exactly you are looking for, but this might give you some idea :

UPGRADING TO FORMS 4.5

Document ID: 108521.841
Title: UPGRADING TO FORMS 4.5
Creation Date: 15 June 1995
Last Revision Date: 16 June 1995
Revision Number: 1
Product: Oracle Developer/2000 Forms
Product Version: 4.5
Platform: n/a
Information Type: ADVISORY
Impact: MEDIUM
Abstract: This document contains information regarding how to upgrade Forms from older versions to Oracle Forms 4.5.
Keywords: UPGRADE, OBJECT PROPERTIES, REFERENCE, FORMS TABLES
____________________________________________________________________________
___
INTRODUCTION
============

This document provides a step by step guide on how to convert forms from older version of Forms, such as 2.3, 3.0, and 4.0, to Forms 4.5.

UPGRADING FROM SQL*FORMS 2.3/3.0
================================

Upgrading from older versions of Forms is a simple process; but it requires that you follow a series of steps and that you have Forms tables installed in the database in some cases.

If you are upgrading from an older forms versions such as 2.3 or 3.0, this is what the upgrade process will do:

1. Take the .inp file and read it according to the format you specify and convert it to an .fmb (binary) file.

2. Convert fields to text items.

3. Convert pages to canvas-views.

4. Convert LOVS (list of values) to Forms 4.5 LOVS and record groups accordingly.

5. Change trigger names names if applicable.
(e.g. ON-VALIDATE-ITEM trigger changed to WHEN-VALIDATE-ITEM)

When converting the triggers, Forms 4.5 generator will not change the trigger text, it will only change the trigger name.
To upgrade, you need to invoke the Oracle Forms Generator either by double- clicking on the Forms Generator icon in windows, or, in UNIX, using the F45genm (motif). You CAN set the following options:

FILE: Name of the Forms 2.3. application (.inp)
USERID: Name of the User
PASSWORD: Password of the User
DATABASE: Database connect string
MODULE TYPE: FORM (DEFAULT)
MODULE ACCESS: FILE (DEFAULT)
UPGRADE 3.0 FORM... [X] CHECKED
VERSION TO UPGRADE 23
Using the command line you can type the following:

f45gen module=filename userid=un/pw upgrade=yes version=23

To upgrade from Forms 3.0 the only value that would change is the VERSION number; however, there is no need to specify the version number when upgrading from Forms 3.0.

When upgrading from a character mode to GUI mode, you will notice that all fields include a bevel to produce a three-dimensional look. The bevel may take up to 1/2 characters per field on some operating systems; the result is that the fields do not display their full value.

To fix this problem, you need to use the parameter WIDEN_FIELDS. This parameter adds one extra character to the width of the text item or field to

allow more space for the bevel. However, you need to be aware of some possible problems:

- If the text items are next to each other horizontally with no space in between them, the items will overlap when the form is upgraded.

- If the text items are next to each other horizontally with only one space, then the text items will have no space in between them.

If you want to use this option, you need to set it in the Oracle Forms Generator as shown below:

WIDEN FIELD DISPLAY LENGTH BY ONE WHEN UPGRADING? [X] CHECKED.

Or, at the command line:

f45gen module=name userid=scott/tiger upgrade=yes widen_fields=yes

Note: This option is set to NO by default.

UPGRADING FROM FORMS 4.0 TO FORMS 4.5
=====================================

It is a good idea to have a backup of all .fmb files that you will be upgrading to Forms 4.5. Once the (.fmb) files are saved as Forms 4.5 files, they cannot be open in Forms 4.0.

The upgrade process from Forms 4.0 consists of two steps:

1. Open the form in the Forms 4.5 Designer.

2. Save it to the .fmb file again or to the database.

You can also create a Forms 4.5 executable out of a Form 4.0 .fmb file and keep the source as a Forms 4.0 file. To do this, perform the following steps:

1. Open the Form 4.0 in the Forms 4.5 Designer.

2. Select ADMINISTRATION--->GENERATE to create a executable (.fmx) without making any changes to the (.fmb) file.

At the command line, you can accomplish the same thing, using the following syntax:

f45gen module=filename userid=scott/tiger

UPGRADING FORMS WITH REFERENCED OBJECTS
=======================================

To upgrade referenced forms, you must follow the next sequence of steps:

FORMS 3.0
=========

1. Make sure that the Forms 3.0 tables and Forms 4.5 tables exists in the same database.

2. The source form must be saved into the Forms 3.0 tables.

3. Upgrade the form as normal and save it into the database.

Again, you need to bring up the Oracle Forms Generator either on Windows or on Motif and set the following options:

FILE: Name of the forms application (.inp)
USERID: Name of the User
PASSWORD: Password of the User
DATABASE: Database connect string
MODULE TYPE: FORM (DEFAULT)
MODULE ACCESS: DATABASE
UPGRADE 3.0 FORM... [X] CHECKED
Forms 4.5 will check both FORMS 3.0 and Forms 4.5 tables in the database. Hence, if there is a table or view missing, you will get ORA-942.

Note: See Bulletin# 106690.304 on how to install base tables for Forms 3.0 and Bulletin# 108383.767 on how to install Forms 4.5 base tables.

FORMS 4.0
=========

Steps to upgrade forms referencing forms to Forms 4.5 :

1. In the Forms 4.0 Designer, open the source form from the database.

2. Save it to the file system (.fmb) file.

3. Open the form into the FORMS 4.5 Designer, and save it into the database.

4. Open the rest of the forms in the Forms 4.5 designer, and save them into .fmb files or into the database.

QUESTIONS
=========

Q. After I convert a source form module to Forms 4.5, can I save it into the filesystem?

Oracle Forms 4.5 allows the user to either reference objects in the database, or in the file system. However, when you first upgrade your forms to 4.5, all source forms used as reference are actually saved into the database, and the forms modules that reference the source forms are looking for this information into the database. To change the reference from database to filesystem, follow the steps below:

1. In the Forms 4.5 Designer, open the source form from the database and save it to the filesystem.

2. Open the form containing the referenced objects. Then, bring up the property sheet of the reference object.

3. Double-click on a property called REFERENCE INFORMATION; this will bring a dialog window with the referenced information.

4. Change the properties as needed: e.g.

----------------- DATABASE----------FILESYSTEM

MODULE:---------- SCOTT.EMP--------- EMP
TYPE:------------ FORM---------------FORM
ACCESS:----------- DATABASE-----------FILESYSTEM
OBJECT NAME:-------EMP--------------- EMP

5. Click OK, and save the form module to the filesystem.

Q. Is there a way to change the reference from database to filesystem globally?

A. This option is not yet available.

REFERENCES:
===========

Oracle Forms 4.5 Reference Manual Volume 2.

____________________________________________________________________________ ___
Oracle WorldWide Customer Support



Query Only Option

From: impact impact [mailto:impact599@yahoo.com]
Sent: 08 April 1999 03:09
Subject: Making Ora Fin forms as 'View only'

Hi all,
I am a newbie to Oracle financial.
I want to make one of the Ora Apps forms - 'Invoice Inquiry' as View only. User should be allowed to view the records. But not update or enter new records. Existing Invoice Inquiry form has a button called NEW. It allows you to enter some records.

How do I disable that option. DO I have to modify the forms. OR can I do something at Ora Apps level itself(someting like 'subfunctions'; then excluding the subfunctions from the User-Responsibility etc)

WOuld appreciate reply. Regards Ora Apps training group Tekedge Corp


Date: Thu, 8 Apr 1999 07:45:58 +0100
From: "Mahendra, Anil" Anil.Mahendra@ncp.co.uk
Subject: RE: Making Ora Fin forms as 'View only'

Look at the function security section in Oracle Applications Standards.

Basically, under Sys Ad or App Dev Responsibility you will need to add QUERY_ONLY"YES" to the parameters of the form in the Form Function definition screen.

If you query this form you will see lots of examples to try out.



Changing Defaults

Date: Tue, 13 Apr 1999 09:17:11 -0400
From: "Manning, Douglas W." Doug.Manning@jhuapl.edu
Subject: GEN: Changing Default value on Oracle Applications forms

Hi All,
I was wondering if anyone in Oracle Apps land could help us out with an Oracle Applications forms customization setup question?

What we want to do is to make a change to the Oracle Financials Import Journals form (GLXJIRUN, we have a copy of this form that we are making our change to called GLCJIRUN) so that the Import Descriptive Flexfields radio button defaults to "Without Validation" instead of defaulting to "No".

What we have done so far is to use the Oracle Forms designer tool to edit our GLCJIRUN Oracle Financials Import Journal form.

We specifically bring up our GLCJIRUN form, then at the Import Descriptive Flexfields property sheet (which is under Blocks, Options, then Items) we change the default value from 'N' (No) to 'O' (Without Validation). We then recompile and generate the form, but when we run the form the Import Descriptive Flexflelds radio button does not default to "Without Validation" but still defaults to "No". We can't figure out why the form does not accept the default value change.

As a side note we are able to make other changes to the form that we can see when we recompile and generate like changing the title of the Radio button "Without Validation" to "Without Hope" (that seems to work just fine), but we can't seem to get the default change to work. We have also made a change to the initialization procedure that is associated with the options block to this form that automatically sets the Import Descriptive Flexflelds radio button to 'O', and that does not seem to effect the change.

If anyone has performed any similar forms customizations or has any ideas on what we might try, your experience on this subject matter would be most appreciated. Our specific product level information is listed below:

Oracle 10.7 NCA
Oracle Applications 10.7.0SC161
Oracle Forms 4.5.10.11.1
RDBMS 7.3.3.6

Thanks, Doug Manning Johns Hopkins University Applied Physics Laboratory Business Applications Group (BIA) (443) 778-3765 Doug.Manning@jhuapl.edu


Date: Tue, 13 Apr 1999 09:38:36 -0400
From: "Steve Hersh" hershs@worldnet.att.net
Subject: RE: Changing Default value on Oracle Applications forms

You may want to take a look at the custom.pll libarary to accomplish the changes you are looking for rather than modifying the bas form.

HTH.



Creating custom form in NCA environment

Date: Tue, 4 May 1999 15:30:08 -0700
From: "Ho, Jan" Jan.Ho@bactc.com
Subject: Help - creating custom form in NCA environment

Hi,
I'm trying to create the custom form in NCA environment. I copied the template.fmb from ../au/1.0/forms/us/ to my c drive and then when I tried to open it, I got an error saying "Cannot find/open 'APPSTAND' module for referenced objects" and then I got another error saying "Cannot attach library APPCORE.pll. This library attachment will be lost if the module is saved".

I found the APPCORE.pll in /au/1.0/resource/ and I copied the files to c:/orant/forms/plsqllib but I'm still having the same errors. I also checked my registry and it seems fine. Our midTier is in Sun Unix.

Is anyone know how to fix it? Thank you in advance, Jan Jan-Ling Chalmers Tel: (650)-827-5055 Cellular One Fax: (650)-827-5488 651 Gateway Blvd, Suite 1500 Email: hoj@cellone-sf.com So. San Francisco, CA 94000


Date: Tue, 4 May 1999 17:47:34 -0500
From: "Logan, Ernie" Ernie_Logan@bmc.com
Subject: RE: Help - creating custom form in NCA environment

You best bet is to copy all of $AU_TOP\resource and $AU_TOP\forms\US\*STAND.fmb to your workstation. Anything less is simply asking for trouble. Be careful of uppercase vs. lowercase in names of pll/plx files. That will bite you using a Unix mid-tier.

Ernie Logan, Jr. | She put me on Earth to accomplish Ernie_Logan@bmc.com | a certain number of things. Right (713) 918-3649 | now, I'm so far behind, I will never 918-1313 (FAX) | die.


Date: Wed, 5 May 1999 08:19:36 -0400
From: phendre@csc.com
Subject: Re: Help - creating custom form in NCA environment

If it is 32 bit windows machine, then you need to look under registry. For my machine it is under
hkey_local_machine/software/oracle/forms45_path.
There is some limitations for the path length. Just put the minimum required path in this.

Praveen.


Date: Wed, 5 May 1999 09:28:37 -0700
From: "Ho, Jan" Jan.Ho@bactc.com
Subject: RE: Help - creating custom form in NCA environment

Hi Ernie,
Thank you for your help. I copied all the pll/plx files and *STAND.fmb files to my share drive and then I added the path to point to my share drive in my registry and it's working fine. Thanks.

Jan



SQL*FORMS

"Carver, Elizabeth" ecarver@MarkAndy.com on 05/12/99 06:57:36 AM

cc: (bcc: Beth Goolsbay/Tul/Energy)
Subject: SQL*FORMS

Hello
Is there anybody out there that has worked with SQL*FORMS? I need to modify an existing Oracle form and can't seem to find the form. I open SQL Forms from user tools and try and get a list of forms but there is nothing in the list. What do I have to do?

Beth Carver


From: goolsbe@mapcocoal.com[SMTP:goolsbe@mapcocoal.com]
Sent: Wednesday, May 12, 1999 11:34 AM
Subject: Re: SQL*FORMS

Beth --
If you're using the "LIST" option within the SQL*Forms tool, it will be looking for the form to be in the database. Most Oracle forms are not stored in the database except during the registration process. If you're wanting to modify a seeded Oracle form (something I don't recommend), you'll need to look in the appropriate $..._TOP/forms directory to find the *inp file. Then, you can use the "LOAD" option from SQL*Forms to retrieve it into the tool.

I'm sorry if I've misunderstood what you're trying to do. I hope this helps.

Elizabeth Goolsbay Sr. Systems Consultant MAPCO Coal, Inc. goolsbe@mapcocoal.inc


"Carver, Elizabeth" ecarver@MarkAndy.com on 05/12/99 11:17:36 AM

cc: (bcc: Beth Goolsbay/Tul/Energy)
Subject: RE: SQL*FORMS

Hi Elizabeth
One more question. I want to make a copy of an Oracle seeded form and make changes to the new form (keeping original form). So when I make changes to the new form how do I save them back to the file and not the database?

Beth Carver


Date: Wed, 12 May 1999 14:18:29 -0500
From: goolsbe@mapcocoal.com
Subject: RE: SQL*FORMS

Beth --
Generally, what we do is copy the seeded Oracle form from the $..._TOP/forms directory to a file that follows our custom module naming convention (i.e. CMGT0001.inp: CMGT being our custom Cash Management module). We then modify the copy (CMGT0001) within SQL*Forms, use the "GENERATE" command to create the .frm and save the .inp files, copy the .inp file to our custom TOP directory ($CMGT_TOP/forms) and register it is a custom form. That's our preferred method.

The next order of preference is to place the modified version, with the custom name, in the Oracle_TOP directory. This is sometimes necessary for the application to find it properly.

If we have to keep exactly the same module name in order for it to work, we make a copy of the seeded form to a *.inp.orig file in the $..._TOP/forms directory and modify the form using the seeded name.

The standard here is to stay as far away from modifying Oracle's code as possible, only moving along the spectrum towards blatant modification of Oracle's code, with Oracle's module name, stored in Oracle's directory, when we have to.

Any other questions, let me know. Elizabeth


Date: Thu, 13 May 1999 09:31:56 -0400
From: "Cathy LaMarre" lamarreca@irctt.com
Subject: RE: SQL*FORMS

Elizabeth,
Usually if we have to make extensive customizations to a sql form, we copy that form to a new form in our custom forms directory. That's the safest to maintain customizations during upgrades. Sometimes we need simple little customizations like setting a default. In this case, we copy the form to a test directory, make the change, test it and copy it back to the production directory.

Here is a tip. If you copy the form to a custom form for extensive customizations, make sure you make the following changes to so it won't bomb out when registering the new form:

1. if creating a new form from OEXOEMOE, the changes all strings of 'OEXOEMOE' to your new form name

2. edit the FND_STARTUP trigger at the form level and change the TITLE

3. make sure your custom application has access privileges to all objects referenced in the original form

Hope this helps. Cathy



Headings on forms

Date: Tue, 25 May 1999 14:16:38 -0700
From: Satish Reddy SReddy@zilog.com
Subject: Headings on forms

Hi folks
We are working on 10.7 NCA.Sometimes we login into multiple instances at the same time.But unfortunately Oracle hasn't provided anything to differentiate between the toolbars/navi/forms from one instance to another.

Could this done through Custom.pll to display the instance name along with the form name ??? Has anyone already done so??

Any help would be appreciated. Thanks


Date: Wed, 26 May 1999 08:49:51 -0700
From: "Haseeb, Mohamed" Mohamed.Haseeb@Jacobs.com
Subject: RE: Heading on forms - INSTANCE NAME

Here is the text file

Regards... Haseeb
========= Instance.txt =========
DISPLAYING DATABASE NAME IN ORACLE APPLICATIONS WINDOW TITLE

Overview

In a typical Oracle Applications (Smart Client) implementation project, there are several databases (instances) that a user can simultaneously connect to. The standard Oracle Application main window displays a generic title labeled Oracle Application, which makes a difficult to distinguish between the various instances that a user may be connected to, from the same computer. This article describes the procedure to display the name of the database that an Oracle Applications session is connected to, in the title of the main window.

Assumption

The solution presented in this article has been tested specifically on Oracle Application Release 10 SmartClient Production 16 (10.7). However, a similar strategy may be used for other releases.

Prerequisites

Experience with using Oracle Forms 4.5 Designer software (Developr/2000) Source code of the following Oracle Applications modules. Navigate form --- FNDSCSGN.FMB (typically located in the FND_TOP/FORMS/US directory of an Oracle Applications client software installation).

Custom Library --- CUSTOM.PLL (typically located in the AU_TOP/RES/PLSQL directory of an Oracle Application s client software installation).

Solution
Step 1
The solution involves making a minor customization to an Oracle Applications form and library. The form name is FNDSCSGN (Navigator Form) and library is CUSTOM. Save a copy of the original form FNDSCSGN.fmx and FNDSCSGN.fmb. Open the FNDSCSGN.fmb form using Oracle Forms 4.5 Designer Software and connect as the APPS database user. Edit the form-level trigger WHEN-NEW-FORM-INSTANCE as follows

Original code:
:global.debug := 'N';
START_UP;

New code:

Declare
App_title varchar2(100)
Begin
:global.debug := 'N';
START_UP;
app_title := 'Oracle Applications: ';
get_application_property(CONNECT_STRING);
set_window_property(FORMS_MDI_WINDOW,TITLE,app_title);
end;

Compile the form and save it.
Generate the form executable FNDSCSGN.fmx.
Copy the new FNDSCSGN.fmx file to the FND_TOP/FORMS/US directory of the
Oracle Applications client software installation.

Save a copy of the original library CUSTOM.PLL and CUSTOM.PLX

STEP 2
Open the CUSTOM.PLL library using Oracle Forms 4.5 Designer software and connect as the APPS database user.

Edit the custom.style procedure as follows:

Original Code:

return custom.standard;

New Code:
if (event_name = 'WHEN-NEW-FORM-INSTANCE') then
return custom.after;
else
return custom.standard;
end if;

Edit the custom.event procedure as follows:

Original Code:

Null;

New Code:

Declare
App_title varchar2(100);
Begin
If event_name = 'WHEN-NEW-FORM-INSTANCE' then
App_title := 'Oracle Applications: ' ||
get_application_property(CONNECT_STRING);
Set_window_property(FORMS_MDI_WINDOW,TITLE,app_title);
End if;
End;

Compile the library and save it.

Generate the library executable CUSTOM.plx.

Copy the new CUSTOM.PLX file to the AU_TOP/RES/PLSQL directory of the Oracle Applications client software installation.

Upgrade

Since Oracle Applications forms and libraries may change upon upgrades, the above changes may have to be re-implemented in the new modules in order to make use of this customization.
========= END Instance.txt =========



Customization of Forms

Date: Wed, 02 Jun 1999 02:46:27 PDT
From: "Krishna Bangalore" vkkrish@hotmail.com
Subject: Reg : Forms Customization

We need to customize forms,mainly the layouts, changing certain field locations and absolutely no change in logics.

Questions
1. When any patches are applied and customized are forms are affected do we need to recustomize these forms.
2. What is the best method of maintenance of such forms.


Date: Wed, 2 Jun 1999 10:05:54 -0700
From: "Haseeb, Mohamed" Mohamed.Haseeb@Jacobs.com
Subject: RE: ORAAPPS-L digest 3251

Krishna,

Normally it is not advisable to customize a form just for layout purposes. I am not sure which form you have mentioned here. If it is the major entry form for the given module (AP invoice entry, PO Entry etc) - don't ever modify as you will receive patches almost every month.

Answer to question 1: When you receive a patch, your form will be overwritten - if you don't rename your form.

Answer to question 2: When you customize your form - save it in a new name and register as a new form. This way when you receive patches, your customized form will be unaffected. But if you need any of those patches - you will have to redo all the changes again on the latest received form.

Again: With custom library and with the folder tools - you can accomplish a lot of such modifications without customizing the delivered form. Try your best to avoid modifying the delivered form.

Regards... Haseeb


FRM-40654 in GUI

(Also please refer another query on this topic - click here)

I'm facing a problem with booking orders from GUI, because of using an event alert on insert or update on SO_HEADERS_ALL to a default a value in an attribute field . We have both 10.7SC GUI and Char in the Char appl it works fine but in the GUI, system gives an error message says : "FRM-40654: Record has been updated. Requery block to see change.

Dose any one has any idea how to solve this problem?

Thanks in advance KHS.


From: Sunil D. Rao [SMTP:Sunil.Rao@ey.com]
Sent: Tuesday, May 25, 1999 10:18 AM
Subject: FRM-40654 in GUI

Hi KHS,

This is a typical error in GUI due to data mismatch while viewing data which have been imported through interfaces like Order Import or by sqlloader etc. and has a trailing blank in the data columns. GUI forms loads such data by truncating the trailing blank and what happens is that when the the record is committed or the user navigates from one field to another, the data column with the truncated trailing blank is sensed by the GUI form as a change done to the column as the same value for that data column is stored in the table with a trailing blank and hence the GUI form raises the message "FRM-40654: Record has been updated. Requery block to see change" I have experienced such errors in NCA R11 too.

The same is not true in character mode, as the the character form loads such data correctly. Please contact Oracle Support for resolving the problem.

sunil rao.


Date: Wed, 9 Jun 1999 09:04:55 +0300
From: Khalid Hussein Al-Sharif Ksharif@savola.com
Subject: RE: FRM-40654 in GUI

Dear Friends

The following message was received by our locale Oracle support in Saudi Arabia.

I hope it will help.

KHS.

From: Oscar Chahestian [SMTP:OCHAHEST.BR.ORACLE.COM]
Sent: Wednesday, June 02, 1999 12:22 PM
To: SATEEQ.SA.ORACLE.COM
Subject: Re: Q: FRM-40654: Record has been updated.

Hi Ateeq

I don?t know if you have the afchrchk.sql script file in your machine. This script fix this kind of error. This error is caused because there are blank spaces on the rigth/left in your data.

You will find the instructions to run into the file. If you don?t have you can ask a patch that contain this file(774541 or 685474).

I hope help you and good luck,

Best Regards, Oscar ----------------------------------------------------------------------------
Oscar Chahestian
Oracle Support Services
Service Delivery Organization
Senior Technical Analyst
Latin America Division
Brazil Office Email : ochahest@br.oracle.com
Rua Jose Guerra, 127 - Andar 1 Voice : (+55)(11)5181-9111
Sao Paulo Fax : (+55)(11)5181-9689
Brazil Mobile:
South America Pager :