I am using the box/spout library for exporting simple Excel files and it is no longer maintained and I wonder what solution I should choose for the current and also future projects.
Box/spout was much faster than the library I used before and as long as you don't need fancy formatting it did, what was needed and in a sufficient fast way.
I wonder which library to use instead now. An export to csv isn't an option since my users are used to the comfort of an Excel file and most are not able to open a csv file in Excel and convert it to Excel format.
I am currently using Symfony 5 and php8.1 in an Alpine Linux container
I know it isn't a direct code question, but I would be glad to know your experience or approach to excel exports in the year 2022.
P.S.: Before I used PHPExcel which was very slow, when you had many rows to export. It got a major refactoring and is now called PhpSpreadsheet but I don't know if they fixed the performance issues with many rows
I am trying to have a java program type into an excel that is shared to several users. Although the java program works fine when no users are accessing the excel file at the time it is run, it seems to create a duplicate file or something entirely new when others are accessing it simultaneously. Is this an issue with my code or is Apache POI just not compatible with a shared excel file? I can include my code but I have a sinking feeling that a simple yes/no will suffice.
i am facing problems reading xls having complex formulas in OptaPlanner, using Apache POI.
Is there any known limitations? Please suggest the resolution steps
The issue here is ADO connection with Excel - is this still the standard way to read/write excel files within a Dephi XE environment? We're coming up with multiple issues when reading/writing using the ACEOLEDB driver (ACE 12) and this includes
Reading cells with hashtags don't return results
"Invalid Floating Point" when exporting grids.
We've also noticed that there's many versions of the ACE 12 driver out on Microsoft's website (via Access Database driver executables) and they each seem to have different issues with Delphi.
With these things in mind,
Is using ADO with Excel bad at this point?
Does anyone else have these issues and what did you do to resolve them (other than using XLS files instead of XLSX)?
ADO in Delphi is leaning to TDataSet model, which mean strictly tabular data... that excel is not. Each excel sheet has a random cells filled, some of those may constitute quazi-tabular ranges, or may not.
Depending on the installed software you can
1) use Excel application to open XLSX, read the cells and pass them to your program. This is most easy and compatible method, though is noticeably slow due to COM IPC marshalling and switching. There are tricks to fasten it, like hiding Excel window, copying arrays of data instead of cell-by-cell approach and such.
Start exploring TExcelApplication component - http://docwiki.embarcadero.com/RADStudio/XE3/en/Using_Component_Wrappers
2) If you do not want to rely on having commercial Excel installed, you may try reading XLSX files with OpenOffice. Vanilla OpenOffice can only read them though, but some other distro's can write them as well. OpenOffice also exposes external APIs both COM-based and HTTP-based. I know there are Delphi projects of Delphi - OOo interacting but personally did not used them and apart of noting that approach i can say no detailed assesment of it.
3) Microsoft also used to sell Office for Developers or such, that gave you Access and Excel kernels as redistributables, that you could pass with your application and install them and use them. Dunno if it is still feasible though.
4) there is a set of commercial components reading and writing those files directly w/o need to have external EXE's doing the job. While that would be the most fast way to work, it would only support some subset of features (which may or may not be ok for your particular goals) and may have troubles with "future compatibility" as Microsoft would roll out updated versions of XLS and XLSX formats (which again may be of some or none concern to you). Like there was TXLSFile for Biff8 format, there is for example OExport library. There is also a component from well known TMS Studio and maybe some more.
5) You can join some open-source project and try to enhance it for your needs, then again that depends upon how much the subset you need.
I know, many people succefulyl use OLE DB to access Excel data, but for me it always sounded as some perversino, because Excel files do not have any internal regular data arrangement at all, less so strictly-tabular RDBMS-like one.
I've really only ever found it possible to manipulate Excel via COM. I've tried alternatives, like ADO, but they always seem so full of archane bugs - or maybe it's just my ignorance.
COM is definitely slow in certain areas. I've used a combination of COM and (within the Excel file) VBA to achieve what I need to do.
Given that Excel is NOT going to go away BUT Microsoft cannot be relied upon not to betray its users by, for instance, doing away with VBA and COM support, it would be great if someone, somewhere (and I wish I had the skills) could create some proper support for Excel from Delphi.
I would like to be able to link some data from a custom application to a cell in Excel.
What tech would you use to do that? I'm primarily a Unix-developer, and don't know win32 technologies in depth. But as far as I understand DDE would be the easiest, even though it is very old tech.
Being able to use it with other office suites such as OpenOffice would be a big bonus.
What does it mean "link data from a custom app to a cell in Excel"?
Do you want the Excel sheet to display data that is generated by some external app?
If that is the case there are a number of options.
The Excel data provider is one way to go. This works if you have lots of data you'd like to load. For just one cell, it may be overkill.
If the external data is accessible via a network interface (let's say, HTTP), then you can write some Excel macro code to consume it. You could use the ServerXmlHttp object to consume it, from within Excel. Some guidance on that is HERE.
Another way to do it is to expose the data via a custom COM object, a re-use construct that is very consumable by Excel. You'd have to write some code to do it, but it's not too complicated. You can write it in .NET, C++, Javascript, VBScript, PerlScript, ...
In .NET I would use the COM libraries for Excel. You can use Workbook, Worksheet and Range objects to address specific cells in specific worksheets and workbooks. These work well from .NET (especially VB.NET).
The COM interface is really easy. You start by recording a macro, and do what you intend to do. After that translate the generated code into the programming language of your choice.
All solutions I have seen here have the approach to push the data to excel.
Why not give the responsibility of pulling this data to Excel itself?
Excel does have the ability to add data through oleDB and ODBC. (at least from the version I know) I can only test that in Office2007, the only version I have on my machines.
All you have to do is add this option to the spreadsheet with the data tab.
Pretty simple. That way you also free yourself from the burden to maintain the code in your app to open Excel, run some code to push the code into the cells etc.
You could probably record a macro for this and run that when the excel sheet is opened.
Easiest way to link to a cell value is via the .net data providers in Visual Studio 2008. Here is a link to some of the more common methods. Link
It's going to be difficult to try and make this available to open office as the data providers aren't the same.
I'd recommend using Java/JVM and its Apache POI library.
It can read and write Excel files and it's pure cross-platform java.
It's pretty reliable in practice.
http://poi.apache.org/
Jonatan,
If the source application stores the data in a database, or a text file, it will be possible to use excels' build in data functions to retrieve it. Otherwise I would agree with Dayton on the integration with VS2008. You can use VS2005, however it will require you to install VSTO.
Regarding DDE - aside of being almost obsolete, there are problems while using different versions of Excel and different languages, which will require you to use different keywords for the same operation
Just to clarify: DDE works with open office. I am a Bloomberg user, and I opened an office 2003 spreadsheet in open office which contained bloomberg links to stock prices updated via DDE, and it works like a charm.