(closed) HTTP 500 error On PCHOLD Format EXL2K

I am getting the HTTP 500 error on my report at the end of the ON TABLE PCHOLD FORMAT EXL2K. The file is quite large and will finish without error if I just ON TABLE HOLD AS holdname. I did a recordlimit and it ran without error at 280,000 and HTTP 500 error at 290,000. I have read that the only limit the Excel limit which in Excel 2007 is the pc memory limitation. Am I wrong? or is there another reason?

This message has been edited. Last edited by: mitch goudy,

Mitch
prod/test WF 7.6.9 WIN

Posts: 15 | Location: Orlando, FL, USA | Registered: December 03, 2003

Francis Mariani

Expert

posted

Hide Post

It is possible the web server cannot pass a file this large back to your web browser, or the web browser itself cannot process a file this large.

According to Microsoft > Office Excel 2007 features that are not supported in earlier versions of Excel, "In Excel 2007, the worksheet size is 16,384 columns by 1,048,576 rows, but the worksheet size of earlier versions of Excel is only 256 columns by 65,536 rows. Data in cells outside of this column and row limit is lost in earlier versions of Excel. ".

Francis

Give me code, or give me retirement. In FOCUS since 1991

Production: WF 7.7.05M, Dev Studio, BID, MRE, WebSphere, DB2 / Test: WF 8.1.05M, App Studio, BI Portal, Report Caster, jQuery, HighCharts, Apache Tomcat, MS SQL Server

Posts: 10577 | Location: Toronto, Ontario, Canada | Registered: April 27, 2005

Ignored post by Francis Mariani posted

Show Post

GamP

Virtuoso

posted

Hide Post

Have you checked the app server log file (as advised by the http 500 error)?
It may be that it tells you that it (the app server) exceeded the amount of memory allocated to it.
If that is the case, you could try increasing the upper memory limit of the app server.

GamP

- Using AS 8.2.01 on Windows 10 - IE11.
	in Focus since 1988

Posts: 1961 | Location: Netherlands | Registered: September 25, 2007

Ignored post by GamP posted

Show Post

mitch goudy

Member

posted

Hide Post

thanks

My output is only 8 columns of data and is failing at 280,000 + rows.

I don't have access to the app server log. My SysAdmin tells there is no useful data to help troubleshoot the error in the log file after my error.

Mitch
prod/test WF 7.6.9 WIN

Posts: 15 | Location: Orlando, FL, USA | Registered: December 03, 2003

Ignored post by mitch goudy posted

Show Post

Waz

Expert

posted

Hide Post

Does it take a long time to get the HTTP 500 error ?, is it a timeout, this could happen in several places.

From your last post, the WF session seems to have finished OK.

Could the WF session finished and removed the spreadsheet before the web server has passed it back ? Have you asked about the Web Server logs ?

Waz...

Prod:	WebFOCUS 7.6.10/8.1.04	Upgrade:	WebFOCUS 8.2.07	OS:	Linux	Outputs:	HTML, PDF, Excel, PPT
In Focus since 1984
Pity the lost knowledge of an old programmer!

Posts: 6347 | Location: 33°49'23.0"S, 151°11'41.0"E | Registered: October 31, 2006

Ignored post by Waz posted

Show Post

dlogan

Platinum Member

posted

Hide Post

Are you using IWA in the environment?

After the error occurs, do you get periodic HTTP 500 error messages elsewhere in the product?

If you are using IIS, more information might be within the Jakarta ISAPI filter logs, or even your web server logs.

I suggest opening a case at techsupport.ibi.com and having it looked into further.

However even if the entire request is not "too big", if the HTTP Header's are "too big" it can cause an HTTP 500 error message.

Typically this is thrown by the Jakarta filter or IIS, which would explain why the application server logs are clean.

Posts: 203 | Registered: November 19, 2007

Ignored post by dlogan posted

Show Post

GamP

Virtuoso

posted

Hide Post

quote:
there is no useful data to help troubleshoot the error in the log file

Which log file did he look in? Was it the IIS log file? If so, then he's correct. But he should look in the app server log file(s) - i.e. the log files of tomcat or whatever product you use that serves as application server. My guess is that the isapi log file is also quite clean, I haven't seen very much useful information in that log file, except when it can't connect iis with tomcat. And since that is not the case here, I expect this file to be of no use. Tomcat's log files however should provide the real reason for the failure. I'd have you SA look into those files.

GamP