I want to use the Microsoft.Office.Interop to read an Excel file from a web page.
Do I need to have Office installed on my web server?
I am not doing any manipulation to the excel file, just reading it in and storing the values to another page. I have no issues when I run on my local machine but I have Excel installed on my local machine. Anyone that knows this answer I would greatly appreciate your input.
Thanks
JD
Using Interop requires that you have Office installed on the server. For websites, I would generally recommend using something like the open-source NPOI project. However, if all you ever want to do is read, consider using ADO.NET (see this question for more info).
I would add that if your using Excel as a datasource the ADO approach is much faster and requires less overhead. It restricts you to excel sheets that are pretty much structured as flat tables. But if I can use that method (all restrictions considered) I prefer it.
Ernie
Related
Is it possible to deploy the new JavaScript add-ins as simple static files using something like Apache? The tutorials suggest ISS or Node.
The add-in that I have in mind has zero interactions with the web, only with the spreadsheet itself.
I would ideally like to just be able to reference the files with file:// URLs but that would be too easy.
Note that I am not talking about VBA, VSTO, C#.Net. Those are all easy. I am talking about the newest, most obtuse technology.
Why suffer the pain? Because Microsoft hates VBA. It is slowly degrading. And eventually I will have to move on. They are fools, because VBA is their secret sauce, but so be it.
Yes. You can host the web application part of an Office Add-in on an Apache server.
So i have this typical problem of distributing an Access application to a client. The application is written in Access 2010 and recently i addded some code to export Excel sheets. Therefore i added the excel object library version 14.0.
My clients that run Excel 2007 cannot run the application anymore getting the infamous error: "mssing or broken reference to the file excel exe version 1.7". The question is this:
If i use LateBinding, will the added functionality be available to them ?
I wish to apologise if the question sounds naive but i am new to VBA.
Yes, the functionality should be available, UNLESS you use features that were not available in 2007 (Some table theme formatting using patterns for example is 2010plus) then you should have no issues using late binding.
I guess the easiest is to simply try. Ideal would be to have a virtual PC running Office 2007 and develop using that, when you are targeting client using a lower version than yourself.
Hope that helps.
Wanted some opinions on which method is a better practice. We have a sales report that MUST be generated in a very specific format (down to the row colors and fonts).
I already have written a macro which pulls from our database and populates the entire workbook in about 15 seconds. The question is how should it be populated?
1) Process server-side: Users initiate the request on the intranet page. ASP.NET opens the workbook template, executes the macro and serves back the final sheet.
2) Process locally: Users download the blank template, run from their desktops which automatically connect to the database.
I like the first one because I can enforce the template, timing, users, and security of the data. But is running Excel automation on an internet web server recommended? I like the second option, but I'm afraid of losing standardization as template sheets begin floating around the company.
As for server side:
I highly.. HIGHLY.. recommend checking out the OpenOffice/LibreOffice XML format for spread sheets.
You can use the localc binary in headless mode to convert the XML file to XLSX or what have you. I use it to create PDF files instead of using ReportLab.
Alternatively here are some other projects that attempt to write to Microsoft formats directly:
http://pypi.python.org/pypi/xlrd
http://pypi.python.org/pypi/xlwt
As for client side:
If you expect the user to be only using Excel and not any other spreadsheet software then go ahead and use an ODBC data source. ODBC will have to be configured per user unless you use some fun VBScript to pull the data from an HTTP server every time it is loaded. There is also the option of making an XLS spreadsheet that simply holds the data and including it into an XLS document as well which would be both a server and client XLS requirement.
Go for server side. Makes information simple to archive and share and will most likely be multi-platform as well.
If you like to use your first option, then you want to avoid using VBA on an installed instance of Excel on the server. This is extremely resource intensive and does not scale well. Instead, if you are writing ASP.NET code, then you should try using the Microsoft Office Interop functionality that is built into the .NET framework. It should possible to adapt your existing VBA code to run under ASP.NET with some changes, but you will have a much more reliable product in the end.
Example Code
However, as #whardier points out in his response, if this were for a large scale or public site, the suggestions he makes would be much more suitable and would scale much further.
I was wondering, if I don't have excel office product not installed on my server, how can I write to an excel document using .net code? I know there's a Microsoft.Inerop.Excel assembly that will assits in this, but it doesn't work for me. I get a CLSID id error where is looking for this particualr guid, but its not installed on my machine. I have the Interop assemblies installed on my server, but I can't use the Excell.Application object. Is there another object that i can use instaed of Excel.Application() to create an excel document on a server where the offce excel product is not installed on? Also my box is 64 bit running SharePoint, if you have any alteratives using SharePoint 2010 I would like to hear about them as well.
Thank You,
There are several Third Party tools, commercial ones like Spire.xls (which we have used, and it works quite well) and freeware, like excellibrary (http://code.google.com/p/excellibrary/).
This has been asked before, see Create Excel (.XLS and .XLSX) file from C# (guess someone may close that question).
I'm a C++ developer wrestling with updating an application that had made extensive use of the IStorage interface to open pre-Office 2007 documents from in-memory storage (via ILockBytes).
If you are still following me so far, you probably know that the new Office Document formats are incompatible with IStorage containers. The application I'm trying to update, relied upon the IPersistStorage interface that all Office applications have, and the code as written calls the load method of IPersistStorage to read in a document from IStorage interface.
So the question is:
What kind of COM interfaces are available to me to read in, from an in memory container, an Office 2007 document?
I've been struggling with pretty much the same problem, to read and write from database storage.
Right now, I'm thinking that the best way might have to be to use the WebDAV-support, and use a web server to implement WebDAV to read from and write to the database.
It's a mess, though... other pointers would be welcome :-)