Page 1 of 1

TM1WEB error when trying to open published excel files

Posted: Wed Jan 05, 2011 1:06 pm
by jvdborre
Hello,

Longtime lurker in here, nice to meet you :)

As the subject states, I'm having troubles with opening excel files via TM1WEB. We're running an x64 server setup. I've tried about everything I could find on the forums, but with limited success.
This includes clearing the cache, registering the ocx and dll, setting the IIS instance (we're on IIS6) to 32 bit, registering the correct ASP.NET version, ..

The error we get to see is the well known 'cannot convert MS Excel workbook to XML".

Apparently, the system does work, when I shut down the tm1excelservice service, start it manually using the -standalone parameter then restart the service using the services.msc console.

So my question is: has anyone ever had and solved the same problem? Does anyone know what the -standalone parameter does, in contrary to running the service as a service?

Thanks for your time
Joris

Re: TM1WEB error when trying to open published excel files

Posted: Wed Jan 05, 2011 1:17 pm
by tomok
I've never heard of the "standalone" parameter but if it's not working when run as a service but does when you launch it as an applicaton I am going to guess the ID the service is running under does not have full privileges to the inetpub\wwwroot\TM1WebEx\ExcelSheet folder. This is where TM1 stores the translation from Excel to HTML files that TM1Web needs. When you open an Excel-based report in TM1 for the first time, the Excel Service looks at the Excel sheet and translates it to HTML, putting some files in a folder underneath the ExcelSheet folder that TM1Web uses. If the ID the Excel Service runs under does not have full security access to ExcelSheet then it's not going to work. The installation should take care of this but I've had instances where I had to manually give those privileges.

Re: TM1WEB error when trying to open published excel files

Posted: Wed Jan 05, 2011 1:28 pm
by jvdborre
Hi Tomok

Your solution seems to solve the problem. Running with the apparently fake -standalone parameter just runs an instance under admin rights, which had the write privileges it needed.

thanks for your quick reply
Joris