Excel CreateObject on server

[Dennis Redfield]

We have a need to instantiate and manipulate excel worksheets
programmatically. Our design call for this must done on the server rather
than on client workstations. Is there any reason NOT to install EXCEL on an
application server (Windows 2000 or Windows 2003) to accomplish this. Do we
need to install a full copy of Excel or is there a more limited approach to
install just enough to allow programmatic manipulation.

thanks in advance.

dlr

 

[Jake Marx]

Hi Dennis,

We have a need to instantiate and manipulate excel worksheets
programmatically. Our design call for this must done on the server
rather than on client workstations. Is there any reason NOT to
install EXCEL on an application server (Windows 2000 or Windows 2003)
to accomplish this. Do we need to install a full copy of Excel or is
there a more limited approach to install just enough to allow
programmatic manipulation.

Typically, this is frowned upon for a number of reasons. Here's MS's stance
on server-side automation of Office apps:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;q257757

There are products out there that will work directly with BIFF, Excel's
native file format. Products like these do not use Excel, and thus you
don't have to install Excel on the server. I've never used any of them, but
here's the one that comes up most often:

http://officewriter.softartisans.com/officewriter-312.aspx

--
Regards,

Jake Marx
MS MVP - Excel
www.longhead.com

[please keep replies in the newsgroup - email address unmonitored]

 

[Bob Phillips]

Sounds like a full version to me. You won't need the dev or enterprise
version, just a vanilla Excel, but definitely a full licensed copy.

--

HTH

RP
(remove nothere from the email address if mailing direct)

 

[Guest]

I'm with Jake on this one - don't do it!

We did it (after reading all the MS advice) and it worked but was well
ropey. we had to write a custom queing component just to manage Excel, we
got many lost instances, the server needed a regular reboot, it only supports
1 user (hence the queue) response time was poor (and it was a fast server).
And you better make extra sure there is absolutely no way anything will ever
pop up a (modal) message box - as it will be on the server screen not on the
users. We had a timed killer to kill instances that were not responding -
but Excel never dies nicely, hence the regular reboots.

Typically you dont actually need the workbook, just some data or results or
something. Ive done similar systems with ADO and XML into and out of Excel
and thats a much better proposition.

When the design decision to put a user app on a server was made had anyone
read the MS advice? If poss I would push back on this based on the MS view
and get a more robust and scalable design. It wont take any longer than
getting Excel to work reliably on your server.

There are also Jave based things which can convert a spreadsheet to a Java
app, but I dont think they pick up VBA.

Also you could try turboexcel to convert your spreadsheet to a native dll.

have fun

cheers
Simon

 

[Dennis Redfield]

well let me explain the whys and where fores:
We are producing reports using Reporting Services. This are done using
subscriptions so the reports are generated without user intervention. The
output from Reporting Services is a file which is an excel object with
multiple worksheets. Unfortunately Reporting Services does not allow us to
name the worksheets - thus they are worksheet 1, worksheet 2 etc. We have
tested using COM automation and vbscript, renaming the worksheets post
generation. This is the step we would like to move to server. So we will
be only using createobject(...) type calls. The user GUI will never be run
and the excel.exe will never be run. Thanks for the link from MS we will
read it this am.


dlr

 

[Peter Huang [MSFT]]

Hi

I agree Jake's suggestion.
Since Excel is commonly a desktop application, We does not recommend or
support server-side Automation of Office.
You may refer to the KB.
INFO: Considerations for Server-Side Automation of Office
http://support.microsoft.com/?id=257757

BTW even if you do want to do that, a Excel application installed is
necessary to use Automation.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[DM Unseen]

Dennis,

I have never done this but you could use ADO to connect to your
workbook and try to change schema's table names(=worksheets names).

see http://support.microsoft.com/default.aspx?scid=kb;EN-US;257819 for
ADO on XL

and

http://www.moon-soft.com/doc/44726.htm

for an example that changes schema names=worksheet names with ADO.

DM Unseen

 

[Dennis Redfield]

Now you are talking! We will look more closely at the ADO connection.
thanks.

dlr

 

[Bob Phillips]

Look at ADOX.

--

HTH

RP
(remove nothere from the email address if mailing direct)

 

[Christopher Baldwin]

Hi Dennis,

Have a look at SoftArtisans OfficeWriter for Reporting Services... it's
a custom designer and rendering extension that lets you have
multiple-sheet reports (and anything else you can do in Excel):

http://officewriter.softartisans.com/officewriter-250.aspx

Best,
Chris