Apache POI is exactly what i needed. Thanks for your advice.
2013/7/15 Mariusz `shd` Gliwiński
> 15.07.2013 12:28, Dennis E. Hamilton said:
>
>> If what you want to *produce* is xls or xlsx, you might want to look into
>> the Apache POI project. That project provides Java libraries for
>> manipulating and producing such documents.
>>
>>
> Thank you for your answer. We need to both - read and write, most of data
> can be processed row-by-row though. Looks like i initially expected too
> much convenience. I'll probably read more about stream-based java libraries
> (originally our software is php). I don't know how realistic is to have
> formulas and colors *stream-based*, however if someone knows about it - i'd
> be glad to hear about solutions like that.
>
> Otherwise, I think the best option is the OpenOffice SDK.
>>
> I tried to fill cells manually and import from database (both using UNO).
> Unfortunately both ways are much slower than what we've had before. If
> there are any other methods to fill the sheets and export, i'd love to try
> them out.
>
> There is, of course, document model and library access available within
>> Microsoft Office and Visual Studio extensions for Microsoft Office. I
>> assume that is not an option for you, although I would think the
>> performance of consuming the documents you are producing might be an issue
>> to address as well, and that might be a better place to address it.
>>
> I've been thinking about using C# on MS Windows + Office, but is it worth
> to setup and maintain the whole new server for it? Is the performance
> difference that big?
>
> PS: CSV is always an option. It doesn't work for formulas and cell
>> coloring, etc., though. There is a form of single-file Excel spreadsheet
>> in XML that might be suitable. There are also HTML formats for XML
>> spreadsheets that might be easier to emit. Your document might be too
>> complicated or too large for these cases. One way to find out is to make a
>> small version having the essential features you need, in Excel, and then
>> see whether and how well those are produced in flat XML and HTML. Then you
>> can examine them for the structure that you need to replicate with
>> greater-sized documents. Scaling experiments can be conducted to determine
>> if these are feasible to produce at your size and also to consume by the
>> intended recipients.
>>
>
> We already have separate code-path for CSV exports, however the client
> insists on XLS. Of course we can make one export for small files (with
> colors and formulas), and another one for simple but large exports. I'll
> still look a bit more for unified solution though.
>
> Thanks,
> Mariusz Gliwiński
>