I have a problem exporting calc files to csv format (version 7 .5 0.3). Sometime the last column is not present in the csv file. This problem did not exist in previous versions of calc It seems to me that if the length of one the column is too large the save file.csv is not correct. Thank you very much for your help.
Created attachment 185460 [details] 2 files in this compress file. The original (.ods) en the file in (csv) different of the original To help I created a source file in ods and saved it as a csv. You will notice that the last column is not present in the csv file Thanks a lot
Can't reproduce. How exactly are you exporting using what settings?
Can't reproduce either with a recent master build nor with LO 7.4. Column H is present in resulting CSV. Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: b52117c0be97c45824d2897657084f8ac7e9bf42 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
I save in csv export by choosing the tab as column separator. I confirm that I did not encounter this problem with version 7.4 of libre office... I believe that the problem comes from the length of the strings of characters in the columns. If a column has more than 60 characters the csv file is not correct The problem is the same when you try to create a csv file from a macro Thank you very much for taking into account this bug
I can perfectly fine save cell contents with 60, 61 or more characters, followed by a column of value 10.
I just tried again with the ods file I sent you and I find the same error (libre office 7.5.03 under ubuntu 22.04) I tried with another computer (libre office 7.5.03 ubuntu 22 .04 and I have the same anomaly. Did you use my ods file? Same problem using an obasic macro Sub ExportCSV doc = ThisComponent url = doc.url rem url =home/arcfidu/gestion pieces = Split(doc.url,"/") pieces(UBound(pieces)) = "import.prn" url = Join(pieces,"/") Dim args(1) As New com.sun.star.beans.PropertyValue args(0).name = "FilterName" args(0).value = "Text - txt - csv (StarCalc)" args(1).name = "FilterOptions" args(1).value = "9,34,IBMPC_850,1,1/2" doc.StoreToURL(url,args) END sub Many thanks to you
With all previous versions of libre office I have never encountered this problem. however with the extension "create csv files" the file csv is correct because it forces to recognize all the columns zones
[Automated Action] NeedInfo-To-Unconfirmed
This morning I created a file with many columns (about 20). Each of the columns had hundreds of characters. This file had hundreds of lines. I saved it with the libre office version 7.4, in .csv format, there was no problem. I tried the same procedure again with version 7.5. The file was not in conformity So I think there is a bug in version 7.5 Thank you very much for your help
(Patrice, the bug reporter can't set the bug to "new" themself, another person has to independently confirm the issue. Please set back to "unconfirmed" when providing the extra information) The settings your macro uses: - a tab separator (ascii 9) - double-quote as text delimiter (ascii 34) - a character set (IBMPC_850) not documented here: https://help.libreoffice.org/latest/en-GB/text/shared/guide/csv_params.html which but I assume matches "DOS/OS2-850/International (Western)" (number 4) - export starting from row 1 - first column (1) formatted as text (2) I tried with the example file and settings in the GUI that match this as closely as possible: - Character set: Western Europe (DOS/OS2-850/International) - Field delimiter: {Tab} - String delimiter: " - "Save cell content as shown" is on, rest is off After saving as CSV, I reopened using the corresponding settings in the import dialog, and I still get the last column H. Patrice, can you please share screenshots of both the Export and Import dialogs so we have the exact settings you use when reproducing the issue? Version: 7.5.0.3 (X86_64) / LibreOffice Community Build ID: c21113d003cd3efa8c53188764377a8272d9d6de CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
(sorry, a screenshot of the export settings should be enough, I can see that the last column's data is missing from the CSV file you sent)
(In reply to Stéphane Guillou (stragu) from comment #11) > - a character set (IBMPC_850) not documented here: > https://help.libreoffice.org/latest/en-GB/text/shared/guide/csv_params.html > which but I assume matches "DOS/OS2-850/International (Western)" (number 4) Yes it does, a very few (9 or so) character sets are supported that way for legacy backwards compatibility.
The bug is identical in version 7.5.1.2 to the one in version 7.5.0.2 Saving an ods file as a csv file is not compliant. I reproduce the same anomaly with the files I sent you. This bug did not exist before the version 7.5 Sincerely
(please keep the version field at the earliest version in which the bug was confirmed, so we know when it appeared) Again, can you please share exactly what settings you use in the graphical interface to reproduce this issue? In File > Save as... > CSV > (name the file) > (confirm) > Export Text File. Thank you!
Dear patrice Lemonnier, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear patrice Lemonnier, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp