This content has been marked as final. Show 8 replies
There have been some significant changes in Java 7U21 which will impact the way CLIENT_HOST and WEBUTIL_HOST will now work. We are aware of these changes and are trying to determine how much of the old behavior we can restore. If your issue only reproduces in Java 7U21, feel free to contact Support and mention bug 16686443
That said, I would recommend using this code in place of yours:
In the above code, :t1 might be a text field where the user would enter the path and name of the file to open. For example: C:\tmp\Docs 2013.doc
Declare my_cmd varchar2(255); Begin my_cmd := 'rundll32 shell32,ShellExec_RunDLL '|| :t1; CLIENT_HOST(my_cmd); End;
Alternatively, if you feel the need to hard code the value, it might look like this:
This code has been tested on Forms 126.96.36.199 using Java 7U21. The same code should work on Forms 10.1.2.3, but keep in mind that Java 7U21 is not supported for use with Forms 10.
Declare my_cmd varchar2(255); Begin my_cmd := 'rundll32 shell32,ShellExec_RunDLL C:\tmp\My Directory\test.xls'; CLIENT_HOST(my_cmd); End;
It appears that this simply removes Java from the equation, which is fine.
However, I can't seem to get the rundll32 method to accept parameters to the Excel file.
It will open Excel, but not get the data from the DB. It then locks the Excel and the Forms sessions. The must be killed via Task Manager.
rundll32 shell32,ShellExec_RunDLL \\my_server\excel\my_excel_file.xlsm /e/35213
The webutil_host.nonblocking was added for Office 2007 and Forms 11g to prevent this type of locking.
Do we go back to the old way?
cmd /c "C:\Program Files (x86)\Microsoft Office\Office14\EXCEL.EXE" /dde \\my_server\excel\my_excel_file.xlsm /e/35213
Windows 7 and XP
32-bit & 64-bit
MS Office 2007 & 2010
some users have admin rights on their boxes (but most do not)
11g Forms on Linux servers
The executable path is found by passing the extension of the file to be opened to the following:
-- Do the registry lookup for the extension v_ExtHandler := Client_Win_API_Environment.Read_Registry ('HKEY_CLASSES_ROOT\'||v_extension, chr(0), false); -- Then see what executable the handler invokes: v_path := Client_Win_API_Environment.Read_Registry ('HKEY_CLASSES_ROOT\'||v_ExtHandler||'\shell\Open\command', chr(0), false);
I looked in the Support site, but there is no indication as to a patch for bug 16686443.
Anyone know anything more on this?
This is a serious production issue, but I see no point in opening a new Service Request since the bug is already defined.
We are nearing a solution which should address the majority of situations. There may be some situations where a minor code change may be necessary, however this apparently may not be avoidable. Because some of the functionality may need to be changed, it is important that you keep this in mind if you decide to not wait for the fix and start coding work-arounds now. Likely some work-arounds will not work after the new patch has been provided and you will again need to make code changes.
I recommend that anyone facing this issue contact Support and monitor the bug I mentioned earlier. Hopefully a patch will be made available soon. Keep in mind that the only Forms versions entitled to a patch are 188.8.131.52, 184.108.40.206, 220.127.116.11, and 18.104.22.168. Older versions would only be entitled if you have an Extended Maintenance agreement which is still valid for that product.
Anyone not using one of the above mentioned versions should consider upgrading as soon as possible for a variety of reasons, this being only one.
To be clear, a fix is NOT* available at this time. This is still under investigation (as of 5/17/2013).