Has anyone had excel template reports that worked and then started causing issues? We have four reports that use templates that were working fine until last week when they would run once or twice and then just sit on the reporting server without returning a report. Until the agent is killed for those staled reports no other template reports will work. Once the agent is killed the report will work again once or twice and then stall again.

Background: We recently changed the legal name for our company. The original templates were updated to include our new logo graphic in place of the old. No code changes were done to the underlying fex files (with the exception of the logo name) or the templates (just new logos). All changes worked in development and uat and only failed when we switched everything over to the new name. We did change all email address' to a new domain so don't know if something there is playing a part.

Any help would be appreciated. We received some help from our IBI guy but it didn't change the behavior. One was to change the agent refresh to 1 under Data Services/DEFAULT to ensure a new agent is used each time the report is run. The other was to copy the template from the app it is stored in to foaccache. That also didn't change the behavior.

This message has been edited. Last edited by: FP Mod Chuck,

Check if it still runs with the old template file, maybe the new template got corrupted. Also check if file permissions are OK.

We tried the old templates and still have the same problem. They will run once or twice and then stall.

We also created a template with some blank tabs and populated those with simple query results. That also started failing after one or two runs.

I think we'll have to open a case with IBI.

Are those templates in xltx or xltm format? We're on 8103. For us the JSCOM3 service does not free it's memory properly, eventually resulting in the service no longer being able to unzip the template files.

Apparently this is fixed in 8202 (or maybe even in 8105).

We have a background process that checks the memory usage of the JSCOM3 service and kill it when it goes below a certain threshold. The drawbacks of that approach are that it only checks periodically for the problem and hence misses some cases, and it also sometimes kills valid processes that just happen to use a lot of the available memory for JSCOM3.

And then... JSCOM3 is also used for other purposes sometimes, such as JDBC based adapters.

It's like a quadruple-edged sword, but it does improve reliability of the Excel services somewhat.

I've had an open problem report with IBI for several years on this or a similar issue. Our issues was with format XLSX that use an .xltm template that use an Auto Open macro, with multiple worksheets in one workbook that exceeded about 7K rows. Anything below that worked fine, after that, it slowed to a crawl. A sheet that would run in about 15 second with EXL2K would take 30 minutes or longer to complete once is reached a certain size. My specific problem is supposed to be resolved in 8.2.02M, at least that is what my rep is telling me. I can't finish converting all of our EXL2K report to XLSX until we upgrade, which, I hope, is going to be very soon. IBI told me that the issue was with how the intermittent work files were being zipped.