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.