We have just moved from Excel 2000 to Excel 2003 and are experiencing problems which we can live with but are frustrating. We are still on Windows 2K and are using IE 6.

We use amperautoprompt for the bulk of our work. The problem occurs when we tick 'Open in another window' and PCHOLD in format EXL2K after we have run the same excel report in the frame to the right of the prompting area. (NB This problem occurs whether or not you have Excel 2003 open as an application). A message in an IE pop up appears:

quote:

A document with the name 'WFServlet' is already open.

You cannot open two documents with the same name, even if the documents are in different folders.

To Open the second document either close the document that's currently open, or rename one of the documents.

If you click on OK, Windows still goes ahead and opens the new window and you are able to view the report.

If you 'run in another window' again without closing the 2 instances of the browser that are open, the above message is hidden and you are confronted with an empty browser. To get to the message you must cycle through the applications using alt-tab. What is peculiar is that the message will appear under either an internet explorer icon or an excel icon - there is no pattern. Interestingly instead of opening the report as 'Sheet 1' on the tab, the report is opened as .xls]Recovered_Sheet2.

If you 'run in another window' yet again without closing the 3 instances of the browser that are open, the above message is hidden and you are confronted with an empty browser again. When you find the message and click on 'Ok', you get the message "cannot open file" and you are placed into an empty instance of MS-Excel (the application not the plug-in).

Ideally you should be able to open as many reports in new windows as you want, but this is clearly not the case. As I understand it this is an Excel limitation, not a Wf problem.

Assuming that other forum users experience the same problem I would be interested to hear how they deal with it and in particular the instructions they would give to their MRE end users who will be less computer literate than us developers.

quote:

Assuming that other forum users experience the same problem I would be interested to hear how they deal with it and in particular the instructions they would give to their MRE end users who will be less computer literate than us developers.

You are not alone, it happens with IE 7 as well. At this point we just put up with it. As WebFOCUS always uses the same output name, I don't know as a way to deal with it. Mozilla Firefox handles the files a little differently than IE, haven't tried the scenario on it yet.

I ran a report three times in Mozilla Firefox using MRE, got a tab for each report in the browser and it prompted to open the file each time. Interesting that it is not that way in IE. IE 7 has tabs available but it does not open a new tab for each run of the report. In Firefox, when I close excel it closes all the reports at once. IE 7 has three IE-excel windows that have to be closed.

Leah,

There is a configurable setting in IE7 that will permit the behaviour that you want.

Have a look under tools, internet options, tab settings and check enable tabbed browsing and the other options that you want.

I think that the main reason IE prompts for duplicate file names is down to the interaction between it and the Excel plug-in. Excel as standard warns before opening duplicate file names and IE has always been troublesome in determining file names from web files such as those created by WF. The thing I am surprised at is that IE doesn't truncate the WFServlet to only 8 chars!!

T

We have had this issue opened with IBI since June 2006. We have tried every browser Setting, file setting, MIME setting and any other settings that anyone could think of...and we still get the message. We could not send a drill down Excel out to Retail Stores because of this problem. At one point IBI told me to call Microsoft. Hey Bill what's happening?

i've just trained my customers to SAVE their first output with a nice name, then run their second event. They seem to think that's a reasonable request, and they're happy.
We're in ie6 as well,and ie7 in test. So i'll test T's suggestions.

You can also tell it to open directly into Excel instead of opening it in the browser's Excel plug-in. Then you don't have to worry about the problems/interaction with the browser.

I have a sollution for this if anyone is interested. It changes the servlet call to an alternate unique name, thereby causing Excel to think it is a different file coming back. It then trapps the servlet name and then internally tells the web app to do the origional request.

Implementing this involves modifying one of the .wfs files for WF 7.1 and lower, or an xml file for 7.6, and introducing a hunk of java code (about a 5 line class) into the WF web application. I offer no guarentees, but I haven't found a problem with it yet. PM me if you are interested.

This message has been edited. Last edited by: dhagen,

What is the syntax for forcing the report to open directly into EXCEL instead of the plug-in. One of complaints I get from my users is that the plug-in does not have all of the features of Excel, like freeze-panes and behaves differently.

No syntax - just management of file types. If you open Windows Explorer>Tools>Folder Options>File Types tab and then scroll down to the XLS (may be XHT as well). Highlight and click on Advanced button. Turn OFF "Browse in same window" option. Anything returned with this extension(s) should now open Excel directly instead of within the browser. BTW, we are on Windows XP, Office 2003, but other versions (including Open Office, I believe) are very similar.
This is managed on the individual machine, so there isn't a magic button to make it work for everyone all at once. But once I got each user to make the change, I haven't had to worry about it again. (until they get a new machine, and of course can't remember how they made it work before)

Darin,

We have tried your solution in the past...and it does not help in our environment. Maybe it will for others.

It also requires a certain level of security (lack of?) on the end users computer which is not the situation in many instances, including my current client. So targeting the "real" Excel will not help my client either.

I have been asked to follow D Hagen's method and will let you know on the success, as it comes, if you would like.

T

D Hagen

Many thanks for an excellent solution. It does cure our problems and as implemented by Tony A. it seemed relatively straight forward.

You can now effectively drilldown in excel although the back button functionality can only be achieved by running in a new window and using the dropdown next to the back button to go back 2 levels because of the re-direct.

That said its WONDERFUL to be free of this annoying problem!

I hope this becomes part of WebFOCUS soon and wish you every success.

Best regards

John

I am interested in the solution by dhagen (below) but have not had a response on the three times that I emailed him. Perhaps he is no longer available at the posted email address? In anycase, if someone has the files / doc, etc. from dhagen for WebFOCUS 7.1 on both an AIX 5.3 AND Windows 2003 platform, can you please send to me?

Also, can someone explain to me WHY it is not a good idea to use /cgi-bin/ibi_cgi/ibiweb.exe? for WebFOCUS 7.1? Is it merely that the CGI will be going away after 7.1? I ask this question because we do NOT get the WFServlet is already open message if the Parent report is rendered using ibiweb.exe and the child/drilldown report is rendered using WFServlet (i.e. different program names). Wondering if recommending ibiweb.exe for WebFOCUS 7.1 is a good / bad idea?

Thanks,
Melodie

dhagen's post:
"I have a solution for this if anyone is interested. It changes the servlet call to an alternate unique name, thereby causing Excel to think it is a different file coming back. It then traps the servlet name and then internally tells the web app to do the original request.

Implementing this involves modifying one of the .wfs files for WF 7.1 and lower, or an xml file for 7.6, and introducing a hunk of java code (about a 5 line class) into the WF web application. I offer no guarantees, but I haven't found a problem with it yet. PM me if you are interested."