I've accessed excel files using desktop applications using OleDbReader, interop, and the latest (and my fav), ling-to-sql. However, this time I need to do so from a Web application using asp.net with C# code behind.
I don't need to create excel files, only read them. Is it possible to do this with a .xls(x), or should I be shooting for .csv?
Looks like they have lots of different solutions posted here: Reading Excel files from C#
Looks like a combination of people recommending ADO.NET as long as the Excel file is pretty straightforward (since there might be "quirks" depending on what type of data you are storing) or different 3rd party tools.
I'd recommend going with CSV. We have a lot of difficulty working with xls files on web servers. Mainly because of Microsoft's restrictive licensing. You'd have to have an Excel license for everyone who'd be accessing the file.. well maybe. That's how it is for us anyway. It might be different under other circumstances. Anyhow, it's not really practical.
Related
This question already has an answer here:
Use Office Interop on ASP.net MVC6 website
(1 answer)
Closed 6 years ago.
I want to generate excel file. That's why I am using Microsoft. Interop. excels library and my work has been done. But right now someone says Microsoft. Interop. excels library is not a good approach for web based projects. It is good for desktop based project. Is it true. If true, so why and what's the issue that approach not suitable for the web. And which is the better approach for generate excel file on web based project.
Actually I have some experience with working with Excel files in both web and windows environments.
My answer to you is that it heavily depends:
Microsoft.Interop.Excel(Let's call it MIE) is cross calling Excel libraries itself to do it's job therefore it's more reliable in case of future versions and better upgradable. But it's not well formatted, there will be no intellisense and most important one you require Excel installed on the running machine.
So base on these info you need to answer these questions:
1- Are you gonna distribute your code or you are going to deploy it?
2- Do you have access to server or no?
3- Is it to create Excel or to read it or both?
4- Is it a project for a long run or a short lifetime one?
1) If you are going to distribute your code find a third party tool. Because if you use MIE you need to tell your customer to install Excel on their machine (which they might be unable to do because of the question 2) and also your code might break because of it's communication issues with MIE.
2) If you don't have access to server (i.e. a hosting deployment environment or your server is managed by your company), you can't install excel on it so let's select a third party tool, compiled in your code.
3) If you want to read excel and you answered the previous questions go for MIE it's a must since most third party tools aren't really good and reliable for opening files. They are mostly able to create ones. Unless you want to create files then you want to use the same files later. Usually third party tools are great in opening files created themselves.
4) If it's gonna work a long time it's better to use MIE because it's essentially better to maintain. Microsoft uses this MIE in their products like Dynamics CRM so they need to keep it backward compatible.
I hope this helps you and it's all based on my own experiences. I'm open to correct myself if I'm wrong so help me in the comments.
I'm looking for options for connecting to (primarily reading data) UNIX/AIX/Business Basic from Windows systems.
I program in C# mostly so would need a .NET solution.
Solutions or comments are welcome.
It depends upon which Business Basic compiler you are using. the most common is BBx, so I will answer your question based upon this particular compiler. BBx will run seamless on Windows or Unix platforms. You can interchange programs between them without recompiling them. BUT, you must have a compiler to make it run. Remember that BBx, ProvideX, Thorobred basic, etc are all M-code compilers, and not P-code compilers. Most people use the utility program that comes with BBx to interchange data between the BBx environment and a web site. Go find the BBx manuals that come with the compiler. You can also use an OPTIONAL ODBC driver. Call Basis International In New Mexico for the driver. Later versions of BBx can also read/write to SQL databases and other types of file systems. But, most BBx programmers will use the keyed file system that comes with it. You can also read/write to ascii files in BBx.
Please note: BBx and all other Business Basic compilers do NOT use flat ascii files. They can write flat ascii files, but, in my 30 years I have never seen anyone use them as a file structure. They are only used to import/export data to/from BBx. The keyed files have a SIT area, Keyed Area, and a Data area. You NEED to read these files in BBx. If you use C or some other language to alter the data in the file, you corrupt the Checksum and the file will become useless. And, you will have one very pissed off customer.
You might also consider getting a BBx compiler for your Windows environment to help you. Pretty cheap option if you don't have source code on BBx side. Remember this ISN'T Basic...it's Business Basic.
You should also find the data structures of the file system on the BBx side. It is very hard to work with the system without it. Some programs will have DBMS on-board, and you can just print out the record layouts to the hundreds of files on the system.
It all depends a lot on the format that is used to store your data. If the data is just flat files, you could use something like rcp or ftp. A number of .NET componentens, both commercial and open-source are available for this kind of access.
If not, you can look for ODBC drivers. There are some vendors that sell drivers for BBX, C-ISAM, D-ISAM, etc..
I agree with Mike, the easiest way would be to use an ODBC. you can find one on the basis web site www.basis.com (they are bbx creators).
If you want fast on the fly access to the data you would be better of writing your own back-end in bbx and have it talk to you C# program using sockets.
I have written an Internet banking app (ASP.NET) talking to a bbx host in this way.
If you need further help feel free to ask.
BBX does has a MS-Dos version. With this you can fully approach all the databases in MS-Dos. With a tool DOSbox you can emulate ms-dos for windows 7 8 and 10.
Within windows you have to assign a windows driveletter to the network and location of your Unix database.
Within BBX it's possible to mount this drive.
Has anybody used/evaluated both of these libraries and can tell me the difference?
Otherwise has anyone here used SmartXLS for reading/creating/updating excel files and can tell me his experience?
The later is considerably cheaper than the former.
I have used SmartXLS for quite some projects for my clients and it works fine for me. I use it to create Excel files from scratch, but also to update existing Excel files (XML, XLS and XLSX). I only have textual information in my sheets. No formulas, images, etc.
In the past, I have encountered a bug once. The SmartXLS team fixed it within one hour after I reported it. Recently, for another project I needed an extension to their library (save as XML). Even despite the fact that I do not have a support contract, they implemented it for me within two days. I wanted to share that they have good customer support, which is for me one of the most important aspects when I purchase a 3rd party library. Disclaimer: I do not work for SmartXLS and am not sponsored.
I have used SmartXLS is several projects to create spreadsheets from scratch, or to use one as template. Sofar everything I wanted it to do, it did. Disclaimer, I neither work for or am sponsored by SmartXLS' developers.
I been searching for the past while for an application which will port a excel workbook to c# code the closest I found was spreadsheetgear but its not of great use, I've slowly come to the conclusion that I will have to write the code myself.
Does anyone know of any freeware command line tool or opensource project which will accomplish this?
The reason that I wish to do this is simple, Excel\VBA is terribly slow even when optimized
some computations can take days, but due to is simplistic use, excel is a standard tool for model building. We have a java port which is dramatically quicker, but we are constantly updating the model and as such each minor change must be checked and recheck which takes time.
My aim is this, have a tool which will take an excel file as input parse all the formulas and values and output c# equivalent code, the few subroutines will be manually ported. A graphical design will then be manually created which will wrap around this generated code.
I have the generally code structure laid out in my mind, how I will accomplish this aswell as the libraries that I will use for reading excel files. But as I'm quite certain this is not an original problem, nor do I think the solution is overly difficult I would presume that there is some public project?
If you want to read Excel files from C# the VSTO Developer Center may be a good start.
As a side note, I think if you are trying to port general Excel applications to C# automatically you have quite a big project. For a small subset of applications where the Excel sheets follow a similar pattern it might be reasonable to do.
But to really benefit from porting Excel applications to C# you will have to rewrite them to use appropriate data structures in C#.
We have an Excel 2002/XP based application that interacts with SQL 2000/5 to process fairly complex actuarial calculations. The application performs its function well, but it's difficult to manage.
We're trying to create a "controller" application or service that can manage and monitor these various instances of Excel (start/stop/process commands etc) but it's a bit of an InterOp nightmare unfortunately.
Does anyone have a good (i.e. working) example of doing something like this in VB.Net or C#?
Don't do it!
We tried for weeks to get something like that to work and it simply does not behave as advertised. Don't even start - give up immediately!
The only options that you really have is a heavy server-side MOSS based implementation - Excel (Web) services (they call it something like that). Windows based COM Excel interop is pretty much dead and will be replaced by MOSS.
The other option is to use SpreadsheetGear. It is actually a fantastic product
It is lightlingly fast
The engine is separate from the UI so you can use it to do Excel stuff server side (with no office installed)
Fairly cheap
Has an API similar to the existing Excel COM api so moving code across is relatively easy
It all depends on the formulas that you need in your spreadsheet. Have a look at the formula list for Spreadsheet Gear and if there is a match go for it.
Interop works fine except that you always end up with references to Excel objects that aren't released, so Excel instances won't close. The following KB article explains why:
http://support.microsoft.com/default.aspx/kb/317109/EN-US/
You can avoid the problem if you have very carefully written code for a limited set of Interop scenarios. But in the general case it's very difficult to get it working reliably.
You might want to take a look at this product: http://www.spreadsheetgear.com/products/spreadsheetgear.net.aspx
It's all managed code and direct .NET libraries. No InterOp headaches. I haven't used it myself, but I've heard very good things from people in the finance world.
We have written a service that controls a single instance of Excel 2003. We never managed to get Excel instances to close cleanly, so we start one instance when the service is first accessed and use only that, serializing client requests.