Hi,
that sound like a bug, there were some discussions before about
save-behavior and ways to save changes back to the same file, however I
think we should not write back to the original file in some obscure
automated way like you describe, can you create a bug-report with the
sample code so one of us takes a closer look?
For now the workaround sounds valid.
Dominik.
On Thu, Jan 12, 2017 at 10:12 AM, Burkhard Losch <burkhard.lo...@kisters.de>
wrote:
> Dear All,
> we use XSSFWorkbook, create it with a file name (not with an InputStream),
> and make modifications on the workbook.
>
> If we close the workbook, sometimes the changes are written, sometimes
> not.
>
> It looks like, if we call the write function with any outputstream, the
> later call to close will overwrite the initial file. But if I don't call
> write, the initial file remains unchanged.
> I think, there are two issues:
> - the documentation says, close only would close the open stream, but in
> fact the source code looks like that changes should be saved back to the
> file.
> - the changes are only written by calling close, if a call to write
> happened before. So, if I want to save the original XLSX file, I need to
> save it twice.
>
> The workaround is, not to use the constructor which takes a File or a
> String, but to use the constructor with InputStream, close the stream,
> make the changes on the workbook and then write it back to the
> inputstream's location with the write function.
> The workbook.close() function is then not required to be called anymore.
>
> Does someone have experience with the correct usage of the API according
> to this? May be I miss some function call, which controls to write the
> file back on close.
>
> The actual use case is :
> use a XLSX workbook as a template
> open the file, write some content, write it back to a new file without
> changing the original template.
>
> I use now the workaround to first copy the template to my destination
> file, open that one with the InputStream constructor, close the stream at
> the end, and write the workbook back with write() to the copied template
> file.
>
>
> Background:
> For our ETL-scripting language KiScript we provide an API for POI, which
> is successfully in use.
>
> This is, how the KiScript code looks like using the workaround, it's
> similar to the JAVA api,
>
> module de.kisters.kiscript.poi.ssf.SSF
> File f = new File("c:\temp\myTemplate.xlsx")
> File target = new File("myDestination.xlsx")
> f.copy(target.getAbsolutePath())
> SSFWorkbook wb = SSFWorkbook.createXSSFWorkbook(target.InputStream())
> SSFSheet sh = wb.getSheetAt(0)
> // write a table to the workbook's sheet.
> sh.writeSheetVertically(Session.getList(), 2, 0, false)
> target.close()
> wb.write()
> wb.writeToFile(target)
> wb.close()
>
>
>
>
>
>
> Regards
> Burkhard
> ------------------------------------------------------------
> ------------------------------------------------------------
> --------------------
> Burkhard Losch - KISTERS AG - Pascalstraße 8+10 - 52076 Aachen - Germany
> Handelsregister Aachen, HRB-Nr. 7838 | Vorstand: Klaus Kisters, Hanns
> Kisters | Aufsichtsratsvorsitzender: Dr. Thomas Klevers
> Phone: +49 2408 9385 -112 | Mobile: +49 176 19671041 | Fax: +49 2408 9385
> -555 | E-Mail: burkhard.lo...@kisters.de | WWW: http://www.kisters.de
> ------------------------------------------------------------
> ------------------------------------------------------------
> --------------------
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
> Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
> irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
> vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
> Weitergabe dieser Mail ist nicht gestattet.
> This e-mail may contain confidential and/or privileged information. If you
> are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and destroy this e-mail. Any
> unauthorised copying, disclosure or distribution of the material in this
> e-mail is strictly forbidden.
