Web.show_document does not open browser anymore

Question

We upgraded our production database over the weekend from 10g to 11g. When it was still 10g, our Forms application used to open a PDF embedded in IE. After moving to 11g, it does not open IE anymore and shows no error messages. Clicking the button with the web.show_document command does nothing. Our test database is also 11g but does not have this problem. What could have gotten wrong?

Answer 1

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:
Suggestion 1.
<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:
WEB.SHOW_DOCUMENT ('http://server/somepath/my.pdf','_blank');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:
-- 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');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>
Suggestion 2.
<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.
-- 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);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:
CLIENT_HOST('C:\Users\<USER_NAME>\Documents\foo.pdf');</blockquote>