Problem description: As soon as there is more than 1 table in the spreadsheet, the CSV save-as target becomes very error-prone. Steps to reproduce: 1. Create new spreadsheet test.ods 2. Create a table table1 with content A1=ABC 3. Create another table table2 with content A1=123 4. Open table2 5. Save as test.csv 6. Warning is shown that only the current table *was* saved Current behavior: Only the currently opened table is saved, whenever "Save" is chosen. Expected behavior: There should be an error message on each save, saying that only the current table was saved. Better would be to prevent the "save as csv" option altogether and add an "export to csv" option. The current implementation makes losing data very easy, because users might expect all tables to be saved. Platform (if different from the browser): Ubuntu 12.04 Browser: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Ubuntu/12.04 Chromium/18.0.1025.151 Chrome/18.0.1025.151 Safari/535.19
Checked with: LO 3.5.4.2 Build ID: own W7 debug build Windows 7 Professional SP1 64 bit Save as csv finished with error message: Warning saving the document Untitled1: Only the active sheet was saved. Save as csv and warning about saving only active sheet follows Excel 2010 pattern. There is additional warning there about saving all sheets as seperate files, giving a different name for each of them or choosing different filetype supporting multiple sheets. Changed Version field to unspecified due to "There is no version named 'LibO 3.5.3 release' in the 'LibreOffice' product." error message.
remove CVS from Save as.. and place it under export, so that the data integrety is saved. Then when a export to cvs occures, you still work in the .ods and every sheet is saved on a save. export means some data is lost but your original remains. save as just let you continue in your document under a different name. It is not strange to make tabseperated plaintext exports from a working document to use them somewhere else. that is why vcs in export is a good thing. btw, never point to a bug in someoneelses program as a reason. especially not when MS is involved. we all know how beautiful they can "motivate" things
If a spreadsheed application cannot edit CSV files (as you propose), it is crap. Therefore, invalid.
To me Simon Claessen's suggestion sounds very plausible, we already had such discussion in "Bug 41100 - After saving as .csv, unexpected behavior causes silent data loss", what has been closed accidently. Problems of that Bug also would be solved (more or less) if we handle .csv as export instead of save as, at least danger of dataloss would be reduced. So I will mar that one as DUP of this one because of the more general approach here @Urmas: May be you misunderstood latest comments? Nobody wants to remove CSV support from LibO, there only are some thoughts how to avoid dataloss for unmindful users.
*** Bug 41100 has been marked as a duplicate of this bug. ***
No, I understood it correctly. Export can happen only once and you cannot usual edit-then-save-then-edit... paradigm with the document in one of 'export' formats. CSV format is fundamental and cannot be treated this way. This suggestion is a sabotage. What next? Make text-only format export-only too? Why that desire to mess up users' workflow?
(In reply to comment #6) I also thought about this problem, this "export" solution only would be acceptable for a document format change from "real spreadsheet" to "csv". A document.csv opened in Calc needs a possibility to save it as csv. But of curse that might be a little unintuitive? Before we change the current behavior still many details will have to be deliberated. My opinion: 99% of all applications where a user creates a .csv from a real spreadsheet he only wants to freeze some contents and has to make it available for an other application. For his own needs he wants to keep the .odt data with enhanced editing, calculation and viewing possibilities. That is very similar to a PDF export or a PNG export from Draw or ... And may be ability to export a range in a spreadsheet as .csv would be a nice feature?
Hi! I want to comment on this bug because I believe it's good to have some input from users to help to decide which way to change the behaviour (or not to change). In my personal experinece, I game looking for this bug (on this subject) exactly because I find the current behaviour counter-intuitive. Moreover, especially the part that the file saved as .csv is logged by LibreOffice on as opnened as that file - it did cause some data loss on my part! At least this behaviour should definately be changed IMO. Moreover, I (personally) use the .csv format exclusively to talk to other (non-spreadsheet) software. Actually, a spreadsheet application is a good tool to prepare some data for other application exactly because of this file format, and I believe (as the previous comment) that this is the way most users use the file format - as an export, not the data storage format. Howver, I understand Urmas's comments too on the part that the ability to save and load from csv needs to be retained - even if it's a minority case, features should not be removed. Although, I have to comment that the claim of this leading to removal of .txt support is a bit of an exaggeration... Anyways, one solution would be to have both - .csv as a saveable file, and .csv as an export format. Is there a reason not to?
The option to 'Save a Copy' was added to WRITER in 4.1 and with https://bugs.freedesktop.org/show_bug.cgi?id=79917 there will also be menu entries for calc. This makes a CSV-"export" without leaving the original ods possible. Does that resolve this issue? IMHO: Using "Save as..." in non ODF format should never change the currently opened document but always do a 'Save a Copy'....
*** Bug 100598 has been marked as a duplicate of this bug. ***
Another option would be if warnings on saves in different formats could be tuned in a more fine-grained way. There is this setting: Tools -> Options... -> Load/Save -> General -> Warn when not saving in ODF or default format The problem is that this warning is probably among one of the first things people turn off, because it's really intrusive, and appears every single time (when a non-ODF type is used). I thinks it would be worth to think about more effective warnings. Like, only warn if one of the changes used a feature that can't be saved properly in the current format. Or show the current format more prominently on the UI, since now when a CSV is opened, only the file name in the top left corner shows that it's in CSV format. One could argue people should pay more attention, but that doesn't change anything, people will keep getting bitten by this. (like this person on reddit today: https://www.reddit.com/r/libreoffice/comments/4tsnx2/mistakenly_saved_as_a_csv/ ) My general question to the UX team: could repeated saving in different, less sophisticated formats be improved to give better warnings to the user, and prevent unintended data loss?
(In reply to Aron Budea from comment #11) > My general question to the UX team: > could repeated saving in different, less sophisticated formats be improved > to give better warnings to the user, and prevent unintended data loss? The dialog says "This document may contain formatting or content that cannot be saved in the currently selected file format Text CSV. Use the default ODF file format to be sure that the document is saved correctly." It has an option for CSV users to not pop-up regularly as well as means to use ODF anyway. I think that's enough. GIMP, for example, changed the way images are saved. Save and Save As produce the internal format only, and you need to _export_ in order to save as PDF, JPG etc. Very annoying, and I agree with comment 1 (closing this ticket as INVALID as suggested in comment 3).