FORMSnn_PATH

Wazzup,
Here is the problem and I am looking for a work around. I am trying to deploy the existing C/S Applications on web. We have more than one applications and some of them uses programs which has similar names.
e.g If we have App1, App2, App3 and App1 has a program called PROG1, so has app2 and app3. Now if the FORMS60_PATH points to <ORACLE_HOME>\forms60 where resides all the runtime, application programs, there arises a name conflict. Now we can resolve this name conflict by putting three separate web/application server for three applications, OR by changing the names of the programs. Where the latter is an expensive idea, the former is too much work because if the program is a pll than I need to detach, retach the pll and recompile 1000s of forms all over again with the new program name. So is there a work around for this or there is a definite solution. If anyone has encountered such a situation and has solved it then could you please help me out.
thanking you in advance
Ranjan
null

Mt.Tam-Luxer wrote:I only noticed, being somewhat a noob, after compiling the NEW Dillo 0.7.3
A very wise decision to use this great browser :-) ... and I'm even serious about that.
Mt.Tam-Luxer wrote:and finding that it places its' executable in /usr/local/bin (!). This, not being in my $PATH by default.
For some reason it is in my /etc/profile ... but I don't remember if I put it there or not.
Firstly, (and as already mentioned more or less) I can see arguments why AL does not include /usr/local/bin by default (mainly because there is nothing there when only installing AL packages).
But OTOH, this is the beauty of AL : you can (and are even supposed to) configure your system as you like by editing the files in /etc. I guess that's why I don't remember, because the first thing I would do if need be is editing /etc/profile ;-) ...
Oh, but something (very general !) to consider : if you want to keep your system "Unix-style", don't put every posible PATH in /etc/profile, but put it in ~/.profile (or whatever shell you are using). If you are the only user, it does not really matter. But in a "true multi-user Unix system" you should not have /funky/path/bin in /etc/ ... not that /usr/local is exotic ....this is more of a general note.
sarah31 wrote:but imho if there is a PKGBUILD for a desired app (such as dillo)
yes, the PKGBUILD for dillo works fine, however, last week they released the latest version 0.7.3 which Mt.Tam-Luxer tried to install ( ... hint ... hint ... package maintainers ... :-) ... ). It was not quite clear from your post if yo wanted him to modify the PKGBUILD script or to just use it.
Oh, and besides changing pkgver, the source should now point to http://www.dillo.org/download/dillo-0.7.3.tar.bz2

Similar Messages

App reverts to old Executable Name when run by AppleScript?

Currently I have an app that I made in AppleScript that does a variety of different tasks when it runs. Part of the task that it performs includes opening up another app which I did not build but downloaded off the Internet (secondaryapp.app).
The original executable name (i.e. the listing under CFBundleExecutable in the Info.plist) of this secondary app is something that is kind of obnoxious and I would really like to change it because I type it in to Terminal a lot so that I can quit the app using the kill command. For the purposes of this post lets just say the original executable name was "old-exec-name." I would really like to change "old-exec-name" to "new-exec-name." To do this I changed both the Info.plist entry and the name of the executable file in the Mac OS folder to be "new-exec-name" and then I archived and unarchived the app to make sure the changes stuck.
When I click on the secondary app (secondaryapp.app) and tell it to open in Finder the program runs fine and the new executable name seems to be working and responds when I use 'killall QUIT "new-exec-name"' in Terminal. However when I use my AppleScript application which launches secondaryapp.app as part of its script the secondary app is run under the old executable name and can only be quit using 'killall QUIT "old-exec-name"' which is exactly what I was trying to change in the first place.
Can anyone explain why is happening and/or how I might fix it please? Any help would be much appreciated.
P.S. I am aware of some other solutions to this such as using aliases in Terminal to avoid typing out the Exec name all the time but I would really prefer to just change the the name. Also I have tried restarting my computer and rebundling the entire AppleScript app from scratch in order to get the app to run under the correct name but I have had no success.

Sherry,
I've had similar problems in the past, and it usually ends up being that FORMSnn_PATH contains a directory with an older version of the form in it. Alternatively, I have found that if the "new" form is invoked from a form that I already have open, then the O/S seems to use a cached version of the target form. Exiting Forms and re-running the app sometimes helps.
Hope this is of some use.
null

Application reverts to old form module

On several occasions when creating an application in Forms 6i, a form module will "revert" to an previous version. Changes are made, compiled and saved and show up on the design/layout canvas, but when the form is run the previous incarnation of the module will appear. The only way I have been able to work around this problem has been to save the module under a new name and drop the old form and change all the associated triggers, etc.
Has anyone else experienced this? Any suggestions?

Sherry,
I've had similar problems in the past, and it usually ends up being that FORMSnn_PATH contains a directory with an older version of the form in it. Alternatively, I have found that if the "new" form is invoked from a form that I already have open, then the O/S seems to use a cached version of the target form. Exiting Forms and re-running the app sometimes helps.
Hope this is of some use.
null

Unable to Open a Form - ROS Error : -200

I am not able to open a fmb. i gives me the error message...
ROS ERROR: -200

hi, from METALINK
FRM-10043 Cannot Open File [ID 32968.1]
Modified 11-DEC-2009 Type BULLETIN Status PUBLISHED
Applies to:
Oracle Forms - Version: 6.0.8 to 10.1.2
Information in this document applies to any platform.
Checked for relevance 2-DEC-2009
Purpose
Troubleshooting FRM-10043 Cannot Open File
Scope and Application
Developer
Troubleshooting FRM-10043 Cannot Open File
General Error Description
FRM 10043 Cannot Open File
A.) Migration & Upgrade Problems
1.) Upgrading SQL*Menu 5.0 menus to Oracle Forms 4.5 menus and am receiving FRM-10043 "Cannot Open File" using f45gen.
Solution Description
Make sure Version to Upgrade = 50 is specified in addition to "Upgrade 3.0 Form, 5.0 Menu ..." when using f45gen.
2.) FRM-10043 Cannot Open File when upgrading Designer generated Files
Problem Explanation
The upgrade process does not correctly handle recursive procedures or stacked canvases with right justified fields residing in libraries. The procedure which was appearing twice was mutually recursive with a second procedure.This was not supported / allowed in Forms 3.0 but it worked and isn't supported and allowed in higher formsversions.
Solution Description
The solution was to strip out all the procedures from libraries, upgrade, and copy the procedures back over a block at a time, padding any right justified fields on stacked canvases.
3.) FRM-10043: Cannot open file when upgrading SQL*Forms 2.3 to Oracle Forms 4.5 using f45gen .
Solution Description
Make sure the 'Upgrade 3.0 Form, 5.0 Menu, or 4.0 Module to 4.5 Module?' Forms 4.5 Generator option is checked. This corresponds to the 'Upgrade' keyword used on the f45gen command line.
Example
Use the following Oracle Forms 4.5 Generator Options to upgrade the 2.3 Form: FILE: < Name of Forms 2.3 .INP File > USERID: < Database User Name > PASSWORD: < Database Password for User Name > DATABASE: < Database Connect String > MODULE TYPE: FORM MODULE ACCESS: FILE UPGRADE 3.0 FORM: [X] CHECKED VERSION TO UPGRADE 23 From the command line, use: f45gen form23name.INP scott/tiger upgrade=yes version=23 module_type=form module_access=file
4.) FRM-10043: CANNOT OPEN FILE when upgrading a Sql*forms 3.0 to Forms 5.0 or 6.0
SOLUTION Description
This feature is not supported in Oracle Forms 5.0 and 6.0. The Forms 5.0 online help says: ""Note: To upgrade a version 3.0 or 4.0 form, you must first convert the form to version 4.5, and then convert the version 4.5 form to version 5.0."
5.) FRM-10043 Cannot Open File when upgrading Menus within Forms 4.5 to Forms 5.0.
Problem Explanation
By setting the flag: Upgrade to PL/SQL from V1 to V2, it caused the upgrade to fail and get the 'FRM-10043 Cannot open file' error.
Solution Description
When you are upgrading from the command line or using Forms Compiler, you should have the menu name in all lower case, and if you do this, make sure you have the extension in the same case.
Example
cl_info_menu.mmb NOT.... CL_INFO_MENU.mmb 6.) FRM-10043 Cannot open file ORA-00600: internal error code, arguments: [17289], [1041], [0x402F44C0], ORA-00600: internal error code, arguments: [17281], [1041], [0x402F44C0], ORA-21779: duration not active when compiling a menu
Problem Explanation
Usage of PLSQL deprecated feature in menu trigger or you are upgrading a 5.0 SQL*Menu menu module to Forms9i/10g created this error.
SOLUTION Description
While compilling use UPGRADE_PLSQL=YES
Example
f90genm.sh module=mymenu.mmb module_type=Menu userid=scott/tiger@cs upgrade_plsql=Yes
B.) Problems Opening Modules
1.) ORA-12203 TNS: unable to connect to destination and/or FRM-10043: Cannot open file and/or ORA-1005: null password given; logon denied by double clicking (opening) the file.
Solution Description
Windows File associations if created automatically by the OS do not enclose a command correctly in quotes. This means that any spaces that are included in your filename or path are interpreted by the OS when passed as parameters. Remove any spaces from the path or filename.
Example
c:/Dependency Analysis/mylib.pll change to c:/DependencyAnalysis/mylib.pll
2.) FRM-10044 Cannot create file, FRM-10043 Cannot Open File on opening file in Forms Builder 6i or 9i if directory name contains Umlauts (vowels)
Solution Description
Don't use umlauts/vowels in the directory name
3.) FRM-10043 : Cannot open file in formbuilder an fmx,mmx,.. (You tried to open a file that is not a valid Oracle Forms design module file)
Problem Explanation
This error occurs when you attempt to open an Oracle Forms form, menu "executable file"
Solution Description
You must open the Binary ( Design ) format of the module. You can open the Form .FMB, Menu .MMB and Library .PLL binary files using the Oracle Forms Designer. If you have a text version of the module, you must first convert the text format back to binary format to open the module using the Oracle Forms Designer. The following shows the file extensions for each type of module and storage format.
Text: FMT,MMT, PLD
Designtime: FMB, PLL, MMB
Runtime: FMX, PLL or PLX, MMX
4.) FRM-10043 : Cannot open file in formbuilder if binary file may be corrupt
Solution Description 1
Transfer the .FMB, .MMB or .PLL file again in BINARY mode, and you will be able to open the file using the Oracle Forms Designer.
Solution Description 2
A module which has been worked on before, but suddenly cannot be opened in the Oracle Forms Designer may indicate that the file is corrupt.
Tests
1. Revert to a backup copy of the Oracle Forms file
2. Open the module from the database, if the module had been saved to the database. You can then use FILE->SAVE AS to save the form to the filesystem.
3. Convert from Binary format to Text Format, and then back to binary format.
Reasons
A form can get corrupted due to a number of reasons, including: A series of changes made to the module in the Oracle Forms Designer could have corrupted the form as a result of some bug The file system might not have had enough disk space to save the module The module could have been transferred over a network, and corruption occurred
5.) FRM-10043 : Cannot open file in formbuilder for upgrade .pld files
Solution Description
Upgrading .PLD files is not supported. When upgrading PL/SQL libraries created in Developer/2000 release 1.X, you must convert all .PLD files to .PLL format before you attempt to open them in Developer/2000 Release 2.0.
6.) FRM-10101 : Cannot generate module or FRM-10043 : Cannot open file for modules saved in the database.
Problem Explanation
FRM-10101 occurs when you try to generate a module that is saved in the database and specify extract=yes, or select "Extract module from database into file?" in the Generate Options dialog window. FRM-10043 occurs when you try to generate a module that is saved in the database, but do not specify extract=yes.
Solution Description
The module name is case-sensitive. When modules are saved to the database, the module name is saved in uppercase.
Example
You have saved a form with module name "mm" to the database.
Using Generate from the command line:
f45gen module=MM userid=scott/tiger extract=yes not f45gen module=mm userid=scott/tiger extract=yes
Using the "Generate Options" dialog window:
File: MM Userid: scott/tiger Module type is FORM,MENU or LIBRARY? Select FORM from poplist Module Access is FILE or DATABASE? Select DATABASE from poplist not File: mm Userid: scott/tiger Module type is FORM,MENU or LIBRARY? Select FORM from poplist Module Access is FILE or DATABASE? Select DATABASE from poplist
Problem Description
This error occurs when you attempt to open a form from the database. Access to the form was granted to the user by the form's creator through: FILE->GRANT->MODULE ( Oracle Forms 4.0.x ) or FILE->ADMINISTRATION->MODULE ACCESS ( Oracle Forms 4.5.x ) and the user name given was public.
Solution Description
Run the grant script to grant access to the Oracle Forms 4.x base tables. Grant access to either the user who is unable to open the form, or to PUBLIC. PUBLIC will allow all users access to the Oracle Forms 4.x base tables.
Examples
Forms 4.5.x (run the script frm45grt.sql as SYSTEM and Forms 4.0.x (run the script frm4grnt.sql as SYSTEM).
7.) FRM-10043 CANNOT OPEN FILE for modules attached libraries or subclassed objects from other modules
Solution Description
- Remove the hard coded path. (For libraries: reattache libraries without path, delete the non portable path). - Check if the library or the other modules are in FORMSNN_PATH. - Check if the env variable for FORMSNN_PATH contains more than 255/512 characters. If yes you can use ORACLE_PATH additional for searching files. (NN could be 40,45,50,60,90)
References
Bug:1317608 WEBFORMS FORMS60_PATH LONGER 512 BYTES DOESN'T RETRIEVE THE FMX
8.) FRM-10043 : Could not open ...olb
Problem Description
Form refers to OLB library with full path. Forms Builder stores full path of opened Object Library in preferences file and will ignore FORMS60_PATH
Solution Description
1. Open Developer preferences file file in any text editor. On Windows preferences file name is CAUPREFS.ORA and is located direcly in ORACLE_HOME folder. On Unix, preferences file is prefs.ora and is in unix user's home folder. 2. Find "Forms.obj_lib_file" entries and remove path info from library file names. 3. Next time Forms Builder starts, it will search for OLB files using FORMS60_PATH.
9.) FRM-10083 : Cannot find/open module for referenced objects. FRM-10043 : Cannot open file.
Problem Explanation
You receive this error trying to open a form in the Oracle Forms designer. The form you are trying to open has referenced objects. The Oracle Forms designer cannot find the source module in the filesystem that contains the definitions of the referenced objects.
Solution Description 1
FRM-10083/FRM-10043 occur because Oracle Forms cannot find the source module in the filesystem that contains the definitions of the referenced objects. If the source module is saved in the filesystem, Oracle Forms uses the following default search path to find the source .fmb file:
1. If the Full Pathname is specified, use that and no other. If you chose Keep Path when you created the referenced object, the complete directory path of the source module would be in the Reference Source Information in the target module. Thus, you must ensure that the source .fmb file can be found in that directory.
2. If Remove Path was chosen, no directory path is specified in the Reference Source Information in the target module. When Oracle Forms needs to locate the source module to read the definition of a referenced object, it looks for the module in the default search path. Oracle Forms will search for the source .fmb file in the following order: a. The Working/Current Directory ( In the icon property for the application on Microsoft Windows ). b. Sequentially in each of the directories named by the value of the environment variable FORMS45_PATH c. Sequentially in each of the directories named by the value of the environment variable ORACLE_PATH
Solution Explanation
When you create the referenced object, Oracle Forms informs you "It is recommended that the fully qualified path be removed."
Solution Description 2
If you have upgraded from a previous version of Oracle Forms, make sure the Reference source form has also been upgraded, before trying to open the referencing form.
Solution Explanation
All applications that are used as the source for references must be upgraded first, followed by upgrading any applications that make references to these source forms.
10.) ROS Error : -200 FRM-10043 : Cannot open file. FRM-11009 : Failed to load color palette.
Solution Description
Make sure that the directory path for the color palette file name is specified, and the file extension is .pal. Also make sure that this file still exists in the file system, and is readable. To check the color palette name and mode that the designer/builder is using: EDIT->PREFERENCES menu or TOOLS->OPTIONS menu The Color Palette field specifies the name of the Oracle Forms color palette that is automatically loaded when you create a new form. If there is any information typed in this field, Oracle Forms will interpret this as a .pal color palette file that must exist in the file system. If this field is blank, the Oracle Forms default color palette is loaded. Thus, if you are not using a custom color palette, this field should be blank.
Solution Explanation
The Oracle Forms designer/builder uses the color palette as specified in the designer preferences or options field to set the visual attributes for the form you are trying to open. If this color palette file is not found or cannot be read, then the ROS and FRM-10043 errors will occur when you try to open form.
11.) Using f60genm to regenerate a form, you get frm-10043: Cannot open file in the .err file and: X Error of failed request: BadPixmap (invalid Pixmap parameter) Major opcode of failed request:54 (invalid Pixmap parameter)
Problem Explanation
You are using AIX 4.3.1 or higher, and the libXt.a file from that OS version is not compatible with Oracle Forms 6.0.
Solution Description
Copy the library file libXt.a (generally in /usr/lpp/X11/lib/R5) from a pre-AIX 4.3.1 O/S (such as 4.3.0) to a directory that won't overwrite your current OS libXt.a file. The $ORACLE_HOME/lib directory is a good place. Set environment variable $LIBPATH to point to that directory. If the customer does not want to copy single file, have them install the following file set from their IBM vendor: X11.compat.lib.X11R5 4.3.0.0 COMMITTED AIXwindows X11R5 Compatibility Library, and set $LIBPATH to include /usr/lpp/X11/lib/R5 instead of the default OS motif libraries.
12.) FRM-10043 : Cannot open file on Apple
Problem Description
see Note:38213.1
13) FRM-10043 : Cannot open file and Form not created If you try to compile a .pll in frmcmp.exe or frmcmp and use the default moduletype=FORM you receive the error.
Solution Description
You have to use Module Type = LIBRARY for .pll or MENU for .mmb or FORM for .fmb

Working with multiple directories

Hello,
I'm trying to configure paths for each type of objects of my project.
That means I'd like Forms (6i patch 13, client/server) to compile in a different directory than the current one (compiling mmx and fmx in two separate directories would be great), to get forms (fmb) in another one, etc.
I know this should be in the documentation, but I just couldn't figure out where (no RTFM please).
Thanks a lot.

Well you can use project builder - but not many people do. So I didn't mention it. Project builder will just be calling ifcmp60 in any case.
As for Paths there are two paths that will be searched as well as the working directory
FORMSnn_PATH where nn is your forms version 50, 60, 90
ORACLE_PATH
There are not separate paths for different module types.
You can also set these paths from the command prompt or from a batch file you don't need to use the registry all the time if you want to change it

FORMSnn_PATH

Similar Messages

Maybe you are looking for