Home » Developer & Programmer » Forms » When PLLs need to be detached and reattached (oracle 10g version 10.1.2.3.0, Windows XP DS; Unix server runtime)
| When PLLs need to be detached and reattached [message #572330] |
Mon, 10 December 2012 19:29  |
 |
lb2mt
Messages: 6
Registered: April 2012
Location: USA
|
Junior Member |
|
|
I am migrating Oracle 6i forms to 10g (ver. 10.1.2.3.0) in Windows XP. The order I have migrated the objects is libraries, menu, forms and reports. All libraries have successfully compiled. As forms and menus are migrated, the migrated pll's are detached and reattached to forms and menus with the paths removed. All objects are named in lower case and referenced in lowercase because they will exist in lower case on the Unix server.
I run the application locally using OC4J in my Windows XP environment by configuring the formsweb.cfg with a named section. The application runs successfully in all of the testing. My forms_path is correctly declared in the default.env and in my windows registry under the <oracle_home> forms_path. When the objects are moved to the Unix server, running only forms and reports servlets, I am told the compilation of the pll's is successful, however, the compilation of the menu errors. It says a call to a program unit in the attached pll 'must be declared' as if it is a variable. It cannot see the pll.
Another developer states the menu must have the pll detached and reattached because something has changed in the pll. I need some assistance in understanding the concept of custom pll attachment.
First, I was of the understanding the main advantage of a pll is the ability to make changes to it without having to go into each form and menu that calls it to detach and reattach the library.
Second, if the pll library compiles in the windows environment, is attached successfully to the menu, as well as any forms that use it, and the code from the pll processes successfully at all times, then those very same objects are moved to the Unix server, why would the menu not see the library? The web server adminstrator showed me the path in the default.env on the Unix server has the library folder and forms folder first in the path before the supplied paths. I have verified a lowercase pll object is referenced in the property palette for the PL/SQL Library Location entry of the library attachment, and a matching lowercase object exists on the Unix server. The pll has even been moved to the same folder as the forms, menus and reports reside but still the menu compilation fails.
I wonder if there is some other copy of a mismatched pll library of the same name somewhere on the Unix server the compiler sees first. I cannot see the files on the server. But also, I do not understand when it is mandatory a form or menu would have to have the pll detached and reattched in order for it to take effect.
Any help would be greatly appreciated. Thank you.
|
|
|
|
|
|
|
|
| Re: When PLLs need to be detached and reattached [message #572415 is a reply to message #572414] |
Tue, 11 December 2012 14:59  |
 |
Littlefoot
Messages: 21808
Registered: June 2005
Location: Croatia, Europe
|
Senior Member
Account Moderator |
|
|
Well, yes, that's what he said - no PMs, please. However, it is an "old" message. Reading what you've written and how you explained what you did, it is not that you don't know anything about migration and need a complete walkthrough. Your problem looks like some specific issue and the answer *might* be written in a line or two. Therefore, there's nothing much you can lose if you do PM David. If you wish, you can explain that it was me who persuaded you to contact him.
Or, you can wait a little bit longer; maybe someone else knows what to do. Also, did you visit OTN forums?
|
|
|
|
|
|
| Re: When PLLs need to be detached and reattached [message #572816 is a reply to message #572416] |
Mon, 17 December 2012 22:31 |
 |
djmartin
Messages: 10181
Registered: March 2005
Location: Surges Bay TAS Australia
|
Senior Member
Account Moderator |
|
|
Via PM "When PLL library attachment fails on Unix web server" from "lb2mt" on "Wed, 12 December 2012 09:06"
-------------
Dear Mr. Martin. I submitted a post and the moderator suggested sending you a PM. I saw your request not to send you one, and I mentioned I didn't want to disrespect your request. Littlefoot suggested with my description of the problem, you might be able to clear up my understanding in a line or two. If you don't mind this intrusion, I would really appreciate your expert advice. Respectfully, Lisa
********************** The post *****************************
I am migrating Oracle 6i forms to 10g DS (ver. 10.1.2.3.0) in Windows XP. The order I have migrated the objects is libraries, menu, forms and reports. All libraries have successfully compiled. As forms and menus are migrated, the migrated pll's are detached and reattached to forms and menus with the paths removed. All objects are named in lower case and referenced in lowercase because they will exist in lowercase on the Unix server.
I run the application locally using OC4J in my Windows XP environment by configuring the formsweb.cfg with a named section. The application runs successfully in all of the testing. My forms_path is correctly declared in the default.env and in my windows registry under the <oracle_home> forms_path. When the objects are moved to the Unix server, running only forms and reports servlets, I am told the compilation of the pll's is successful, however, the compilation of the menu errors. It says a call to a program unit in the attached pll 'must be declared' as if it is a variable. It cannot see the pll. Another developer states the menu must have the pll detached and reattached because something has changed in the pll.
I need some assistance in understanding the concept of custom pll attachment.
First, I was of the understanding the main advantage of a pll is the ability to make changes to it without having to go into each form and menu that calls it to detach and reattach the library.
Second, if the pll library compiles in the windows environment, is attached successfully to the menu, as well as any forms that use it, and the code from the pll processes successfully at all times, and the calls and objects names match in case, then those very same objects are moved to the Unix server, why would the menu not see the library?
The web server adminstrator showed me the path in the default.env on the Unix server has the library folder (1st) and forms folder (2nd) in the path before the supplied paths. I have verified a lowercase pll object is referenced in the property palette for the PL/SQL Library Location entry of the library attachment; no path entry was saved to the attachment. A matching lowercase object exists on the Unix server. The pll has even been moved to the same folder as the forms, menus and reports reside but still the menu compilation fails.
I wonder if there is some other copy of a mismatched pll library of the same name somewhere on the Unix server the compiler sees first. The web administrator says there are no other objects of the same name in some other folder. I cannot see the files on the server. But also, I do not understand when it is mandatory a form or menu would have to have the pll detached and reattched in order for the pll to be recognized.
Any help would be greatly appreciated. Thank you.
-------------
David
|
|
|
|
| Re: When PLLs need to be detached and reattached [message #572817 is a reply to message #572816] |
Mon, 17 December 2012 22:33 |
|
djmartin
Messages: 10181
Registered: March 2005
Location: Surges Bay TAS Australia
|
Senior Member
Account Moderator |
|
|
Via PM (replied) "Re: When PLL library attachment fails on Unix web server" from "djmartin" on "Mon, 17 December 2012 14:34"
-------------
Lisa,
Thank you very much for having read and followed my request. I haven't read your post but as Littlefoot has recommended that you contact me I can only assume that LF couldn't help you.
I don't have Forms on my machines so the following is from memory.
Is there a directory in the path which is empty?
Is there a directory in the path which has a space in its name or is longer than 32 characters?
I strongly recommend that all Forms objects (object libraries, code libraries, menus, forms, and reports) live in the same directory. It reduces your ultimate 'path' length.
I also recommend that you do not compile your code libraries. (I believe that I have explained my reasoning behind this statement somewhere in the forum. Have quick search for 'pll plx david' and see if you can find it. Don't panic if you cannot, just move the 'plx' files to a temporary directory and run some tests.)
[Look at http://www.orafaq.com/forum/mv/msg/143277/395551/67467/#msg_395551 - I may have been a bit harsh but I DO like my questions answered.]
[Also read http://www.orafaq.com/forum/mv/msg/78762/448548/67467/#msg_448548 - "Have you placed the name of your PC's forms directory in the 'Start in' for your Forms Builder?" This one may not be applicable to your Unix problem but is in the Windows environment. When you do your batch Forms regeneration and compile are you running in the Forms directory or in the Oracle object directory?]
I can't remember whether you have to specify the extension when attaching a library. Did you attach the 'pll' or the 'plx'? I don't think you need to specify either - test it. The reason you had to reattach the libraries was to get rid of the path but as you no longer have a path in the property of the Form you do not have to repeat this exercise.
Read http://www.orafaq.com/forum/mv/msg/128639/380017/67467/#msg_380017 and http://www.orafaq.com/forum/mv/msg/49984/131655/67467/#msg_131655 and always do the Ctrl-Shft-K compile.
I believe that you should have read access to both the development and test versions on the Unix machine. Otherwise, how can you see to fix a problem. If your administrator has problems with this concept get them to PM me.
David
PS If you don't mind, I would like to post the above to your original question. Please supply the link if you are okay with this.
-------------
David
|
|
|
|
| Re: When PLLs need to be detached and reattached [message #572819 is a reply to message #572817] |
Mon, 17 December 2012 22:40 |
|
djmartin
Messages: 10181
Registered: March 2005
Location: Surges Bay TAS Australia
|
Senior Member
Account Moderator |
|
|
Via PM "Re: When PLL library attachment fails on Unix web server" from "lb2mt" on "Tue, 18 December 2012 08:31"
-------------
Quote:Is there a directory in the path which is empty?
Not that I am aware of, but the following alludes to something similar. I apologize, I am not a web administrator so I cannot speak to Unix with any authority.
I searched OTN Forums and found an article, which I forwarded to our web administrator: Oracle Application Return The following Error FRM-40735: ON-ERROR trigger raised unhandled exception ORA-6508 [ID 797293.1]. The document says to determine that the custom.pll and custom.plx files did not exist in the $AU_TOP resource directory structure. $AU_TOP did not mean much to the administrator, but shortly after, it led him to add the "ld" directory to his server definition. I do not know specifically where. After he stopped and started the server, it saw all of the objects. The menu compiles with the attached library and the application now runs as expected.
Quote:I also recommend that you do not compile your code libraries. (I believe that I have explained my reasoning behind this statement somewhere in the forum. Have quick search for 'pll plx david' and see if you can find it. Don't panic if you cannot, just move the 'plx' files to a temporary directory and run some tests.)
Thank you! I will research this topic. More than one of us have the impression *.plx must be on the server for the application to run.
Quote:"Have you placed the name of your PC's forms directory in the 'Start in' for your Forms Builder?"
The administrator showed me the forms and reports path was in the FORMS_PATH on the Unix server, but it did not change the problem before he found the "ld" solution noted above. Thankfully, I have had my Windows environment configured accurately for this process, and I have been able to test most of the 6i to 10g migration efforts locally for all of the applications I am migrating.
Quote:I can't remember whether you have to specify the extension when attaching a library. Did you attach the 'pll' or the 'plx'? I don't think you need to specify either - test it. The reason you had to reattach the libraries was to get rid of the path but as you no longer have a path in the property of the Form you do not have to repeat this exercise.
When I attach a library to a form or menu using Forms Builder, the 'Browse' popup window defaults to the .pll extension for file type. There is a drop down to choose *.*, but I never use that option.
Quote:PS If you don't mind, I would like to post the above to your original question. Please supply the link if you are okay with this.
I realize we are a bit late migrating to an outdated product as 10g, but by all means, if any of this dialogue can assist someone else, please attach your reply to my original post. The link is: http://www.orafaq.com/forum/m/572330/171932/#msg_572330
I greatly appreciate your willingness and your time in helping me, Mr. Martin.
Respectfully, Lisa
-------------
David
[Updated on: Mon, 17 December 2012 22:41] Report message to a moderator |
|
|
|
|
|
| Re: When PLLs need to be detached and reattached [message #572918 is a reply to message #572820] |
Tue, 18 December 2012 10:17 |
|
lb2mt
Messages: 6
Registered: April 2012
Location: USA
|
Junior Member |
|
|
The web administrator is having difficulty with another application ported to the Unix server. The objects are not compiling against two objects libraries that exist in the folder with the form, menus and report objects. Compiling against these libraries in the Windows XP development environment went flawlessly. I think he will need to research the issue as I am still without the ability to see objects on the server at this time.
We are much farther along than we were. I think I have taken up enough of your time. I appreciate all of your help and that of Littlefoot's, too.
Happy Holidays and the best in all things for 2013.
Lisa
UPDATE: In researching the forum for the error: FRM-18108: Failed to load the following objects
, I think the administrator needs to validate he has added the path to this newly added application in his Unix server
FORMS_PATH. If that is the situation, I will edit this post to confirm.
[Updated on: Tue, 18 December 2012 11:55] Report message to a moderator |
|
|
|
|
|
Goto Forum:
Current Time: Thu Apr 25 20:28:17 CDT 2024
|
] 
Blog
Search
Help
Members
Register
Login
Home
I will post the original message on OTN forums, too.