This content has been marked as final. Show 8 replies
The database has nothing to do with a WEB.SHOW call. Likely something else changed. For example the JRE version. I would recommend trying something simple. For example do the following:1 person found this helpful
1. On a failing client machine, close ALL open browsers
2. Clear the JRE jar cache. This can be done from the file system or in the java control panel.
3. If you have more than one JRE (including Jinitiator) installed, uninstall ALL versions except the one you plan to use.
4. Create a simple form using the v11 Builder. Add a canvas, a block, and one button. In the WHEN-BUTTON-PRESSED trigger add this code (assuming the machine has internet access):
If this works correctly, it will open the Forms 11R2 New Features document.
Now retest your original failing form. If it still fails, I will assume you have a coding problem or compatibility issue. In this case, please provide exactly which Forms version you are using, the JRE version, the client OS, and any other details about what your app is trying to do. I would recommend you include the WEB.SHOW call you are making.
I neither works, I would recommend looking closely at things like virus scanner software updates and any other security software which may be installed on the machine.
I cannot create a sample 11g Form because ours is still 10g. The issue is happening throughout all of our users. What they normally do with the form is click the button to view a PDF file that is stored in a Windows filesystem.
The code behind the button is WEB.SHOW_DOCUMENT('file://' || <pdf_location>, '_blank');
Our Forms version is 10.1.2.2.0
Client OS: XP Professional SP2
Java: 1.5.0 (build 1.5.0_11-b03)
Edited by: paulcruz on Jan 15, 2013 2:21 PM
Edited by: paulcruz on Jan 15, 2013 2:26 PM
Edited by: paulcruz on Jan 15, 2013 2:28 PM
Well, you answered my question. Your issue is in the code. Attempting to open a file on the local file system was considered a vulnerability so it was restricted. For this and other reasons I do not recommend performing this operation in this manner. However, if you are not willing to update your code, a solution was made available for Forms. The solution, as I recall requires several steps:
1. The first step is to patch Forms to 10.1.2.3 (patch ID 5983622)
2. Install the Forms Bundle patch (ID 9593176)
3. Then follow the instructions in the Patch Readme and follow MOS note 1188127.1
4. You may find it necessary to also upgrade to JRE 1.6.0_28 or newer. I would recommend that you upgrade to 1.6.0_38.
Edited by: Michael Ferrante (Oracle) on Jan 15, 2013 6:27 PM
But why is this issue not occurring in our test database, where it recently became 11g? How do I update our code, as you are suggesting?
Edited by: paulcruz on Jan 15, 2013 4:12 PM
Not sure if this helps, but I've seen situations where web.show_document was considered to be a pop-up and blocked due to that. We had to unblock pop-ups from that server.
I can't explain why it seems to started failing all of a sudden. We often hear comments like this only to later discover that either someone else made changes of which you are unaware or possbily a software update occurred automatically. For example, the JRE version may have been auto-updated.
As for recoding in an alternative fashion, it will be difficult for me to say specifically because I don't know the app nor do I know your needs. The biggest, and it isn't all that big, deal will be to identify from where the pdf being opened comes from. In other words, does it already exist on the client machine or is it downloaded to the client from the/a server? Also important to know is whether or not the file name is known or not.
So, if you want to change the code, first figure out how you want the application to complete the task. Here are my suggestions:
<blockquote>If the file (pdf in your case) originally resides on a remote server, then leave it there. The document can be opened using a direct url to the file on the remote server. For example:
If the file lives within the Forms directories, you can even use a relative path rather than the fully qualified one above. For example, if the files live in \forms\java\foo then you can do this:
This makes the application a little more flexable given that you would not need to change the app code if the server name changed. Once the file has been opened on the client side, whatever pdf reader the end-user is using will offer a "Save" option. So if they choose to save the file locally, they can do so as they desire.</blockquote>
-- The exact entry may differ slightly depending on which -- Forms version you are using and where you locate the files WEB.SHOW_DOCUMENT ('/forms/java/foo/my.pdf','_blank');
<blockquote>If, for whatever reason, the file is downloaded to the client or just happens to already exist on the client, you can use WebUtil's CLIENT_HOST (or WEBUTIL_HOST.HOST) command to open the file locally. There are several ways to do this and which method you choose will depend on a few factors. For example, are all the client machines Windows based? I will assume, for this example that the client machines are Windows based. And, because I like to write code as generically as possible, here is a way to open documents on Windows without the need to know which application normally handles it. In other words, you don't need to know that it will be Adobe Acrobat that opens pdf files or that MS Word will open doc files.
This is a bit of an old school way of accomplishing the task, but it is very effective and flexiable. Alternatively, you could use CLIENT_HOST to directly call the file, but this may not always work. For example:
-- In this example, the value of myPathAndFile is the path and filename. -- For example, myPathAndFile := 'C:\Users\<USER_NAME>\Documents\foo.pdf'; CLIENT_HOST('rundll32 shell32,ShellExec_RunDLL '|| myPathAndFile);
I work with Paul and just discovered that if we try to pull up the PDF file using Oracle Web Cache, it fails. If we try bypassing Web Cache it succeeds. So, the problem seems to be something with the configuration of Web Cache. Our test system uses Web Cache also, so I can compare the setup between the two environments. So far, I haven't found a difference that would matter. The differences are all the kind one would expect, such as the server names.
Does anyone have any suggestions how Web Cache could cause this kind of problem to occur?
It is possible that W/C is sending back the wrong or no mime type and therefore the browser doesn't do the right thing. You will need to review the W/C documentation to understand what configuration changes are possible.
I would recommend taking a step back and removing Forms from the testing. Stage a pdf file on the mid tier some place that has a virtual path. Then try accessing if via the W/C port. Does the same failure reproduce?