Description: CALC spreadsheet failed to save to dBASE format. If the second row of a given column contains only numbers, it is incorrectly saved. In this case, you treat the column as a number type and place a zero in the character type cell. Screenshots link: prnt.sc qo5h99 https://prnt.sc/qo5h99 Steps to Reproduce: 1. FILE / Save as / dBASE (*.dbf) type ( valami.dbf ) 2. Just Use dBASE formatum 3. Export dBASE format: (DOS/OS2-852) 4. Click OK. 5. Close file 6. Open last document ( valami.dbf ) Actual Results: Zero digits appear in the character cell Expected Results: You should have saved the original content. Reproducible: Always User Profile Reset: No Additional Info: This error is present in all versions.
Created attachment 157164 [details] screenshots
*** Bug 130019 has been marked as a duplicate of this bug. ***
You can't have columns of mixed types in dBase. If the first data row's cell has numeric content then numeric/Decimal type is assumed, similar for boolean/Logical and Date. However, you can force a field to type Text/Character by appending ",C" (without quotes) to the field name, so in your case that would be "CODE1,C". Then numeric cell content is converted to text for export. All columns' data could be scanned whether they contain mixed types and then switch to Character type, but.. that's rather a data layout error.
ScDocShell::DBaseExport() for this case even sets SCWARN_EXPORT_DATALOST error code, but for some yet unknown reason a message is not displayed or the error not propagated later.
At least since 5.3 (don't have earlier versions at hand).
(In reply to Eike Rathke from comment #3) > You can't have columns of mixed types in dBase. If the first data row's cell > has numeric content then numeric/Decimal type is assumed, similar for > boolean/Logical and Date. However, you can force a field to type > Text/Character by appending ",C" (without quotes) to the field name, so in > your case that would be "CODE1,C". Then numeric cell content is converted to > text for export. > > All columns' data could be scanned whether they contain mixed types and then > switch to Character type, but.. that's rather a data layout error. The ",C" post-field-name addition is not a bad idea, but doing hundreds or 1000 columns is a big job. It would be better if you took the dBASE data field type from the table column type.
There is no such thing as a "table column type" in a spreadsheet.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6a308d2bfaf1d756aa4cfca6a40b80cf5e88e5fa Propagate warning error code from dBASE export, tdf#130020 It will be available in 6.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/02ca7b1c92a801004a42c92c59f4bbfc70ec19eb Propagate warning error code from dBASE export, tdf#130020 It will be available in 6.4.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Dear Athos, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Eike, I have seen your commits here, is this bug solved? Or still things to do?
I don't remember.. but assume it's resolved.
Testing with: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 91358f11ee7e87c8c8290b9507f64d8f90aac3ea 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 can see the warning when a mixed column with numbers and characters will be converted to a numeric-only column (replacing strings by 0). No warning back in 5.4. Was the same in OOo 3.3, so marking as inherited. Marking as fixed by Eike. Thanks!
Created attachment 189143 [details] sample ODS file to test with See effect of saving as dbase on first column.