open a DBF in Calc and use "Save as" to save it with another name as DBF seems to work copy a table in Base and insert it in Calc looks a little strange but seems to work too. But when saving it as DBF, it is totally brooken (no DBF anymore) Martin
Martin: Can you please attach here the .ods produced by that operation, that fails to save as DBF? Thank you!
Created attachment 46683 [details] File with bug 32670, writing to DBF gives failure
Writing content to DBF gives: General Error. General input/output error. OS: Ubuntu 11.04 OpenOffice 3.2.1 gives no failure.
Hi all, I can not reproduce with my own tests on Mac OSX 3.4b5. If I copy a table from a mysql db containing a timestamp field, a character field, an integer field, a double field, they appear in Calc fine. Then I can save them as DBF. Close, re-open the DBF, eveything still OK, the header columns have been changed to define the field format, but that also happens with OOo (and has always done as far as I can remember). If I then save the DBF as another DBF (different name), and then re-open the renamed file, everything still appears OK. Something particular about your file ? Have you tried with the latest 3.4 beta5 ? Alex
@ Alex You need to have a DBF-application - reopen the wrong-formed DBF in OOO/LO works fine However: still worthless Look at attached screencaptures: zaehler,N,19,0 (that is correct) - becomes zaehler,N,7,2 (wow!) Now the digits are justified correct (right to left) , but inserts a decimal+00 and changes the format Fun: it shortens the fieldlength and makes it dynamic - in regard to the longest number in that column. I do not know, whether this will have any effect when reopen in real DBF-applications, lets see. that happens on decimals only, not on text-fields. Yes, this is 3.4 Beta5 Martin
Created attachment 46878 [details] format-changes N,19,0 to N,7,2
oops - comment 5+6 mailed to the wrong issue (should have been 32672) can some delete that? sorry martin
@ Alex gave it a try with LO 3.4 Beta 5 and LO crashed immidiatly on crtl-v (not the only thing, when LO crashed) Martin
Very old bug ... @reporter: Still a problem for you wiht 3.4.3? If yes, please read hints on <http://wiki.documentfoundation.org/BugReport> carefully! Then please: - Attach screenshots with comments if you believe that that might explain the problem better than a text comment. Best way is to insert your screenshots into a DRAW document and to add comments that explain what you want to show - Contribute a step by step instruction containing every key press and every mouse click how to reproduce your problem. - add information -- what exactly is unexpected (as Tor said, all effects very carefully and complete) -- and why do you believe it's unexpected (cite Help or Documentation!) -- concerning your PC (especially: video card) -- concerning your OS (Version, Distribution, Language) -- concerning your LibO version and localization (UI language) –- Libo settings that might be related to your problems -- how you launch LibO and how you opened the sample document –- If you can contribute an OOo Issue that might be useful -- everything else crossing your mind after you read a.m. URL May be you can test <http://wiki.documentfoundation.org/BugReport_Details> for submitting bug reports?
Comment on attachment 46878 [details] format-changes N,19,0 to N,7,2 Obsolete due to Comment 7
I just check the problem with LO 3.4.3 on W2K: no changes Copying a table -- from odb bound/connected to DBase: functions (partly) -- from an odb connected to HSQL-tables: impossible I can not reproduced it with mysql, because I do not have that. attached: screencapture pls look at the related issue id=32669 m.
Created attachment 52554 [details] the source (in HSQL) and the result of copying and of saving as DBF
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
needinfo keyword redundant by needinfo status.
I will try to interest someone with DBF knowledge for this issue.
LOdev 3.5.0 Build ID: 7362ca8-b5a8e65-af86909-d471f98-61464c linux After copying from Base to Calc, the cells in D262 and D426 get changed from: '4872PM to a time format: 4884:00:00 If I try to save the copied spreadsheet I get an 'Write error. Cell D262 contains a string that is longer in the selected character set'. I'll attach screenshots.
Created attachment 54913 [details] Screenshot showing Cell 262 error
Created attachment 54914 [details] Screenshot showing Cell 262 as: '4872PM
Created attachment 54915 [details] Screenshot showing Cell 262 after copy from Base
Added note: If the file is saved as a .dbf, Base doesn't recognize the file as a dBase file & it's necessary to open as a spreadsheet instead.
Just tried revisiting this with LO 3.5.5.2 on Linux Mint 12 64bit. Opened submitter's Calc file. Seems to open without errors. Saved as DBF, selecting EURO codepage. Read dbf file via dbview command line utility, no I/O errors, and the display seems OK This looks solved for me. Can we close ? Alex
(In reply to comment #21) > Just tried revisiting this with LO 3.5.5.2 on Linux Mint 12 64bit. > > Opened submitter's Calc file. Seems to open without errors. > Saved as DBF, selecting EURO codepage. > Read dbf file via dbview command line utility, no I/O errors, and the display > seems OK > > > This looks solved for me. Can we close ? > > > Alex Oh darn, just realised that there are 2 reported buggy behaviours in this report: (a) copying from Base to Calc (b) exporting from Calc to DBF As far as I'm concerned, (b) works fine for me. Haven't tested (a) here because submitter has not provided an ODB file, or even the DBF file to which Base is supposed to connect, only a Calc file. Alex
Tested on LO 3.5.5.2 with : /usr/lib/R/library/foreign/files/sids.dbf 1) Copied sids.dbf into my declared DBF folder. 2) Opened the ODB file referencing the DBF folder. 3) Opened a new Calc document. 4) Right-mouse button click on table sids in the ODB file, then selected Copy. 5) Clicked on Calc sheet, then Ctrl-V 6) Data from DBF file correctly copied over from Base to Calc without any visible formatting problems. 7) Save Calc sheet as DBF. 8) Opened new DBF file with dbview command line utility, data seem to be same as in original DBF file displayed in Base,and the data copied over to Calc. Conclusion : can not reproduce the problem. Alex
Hi *, > Conclusion : can not reproduce the problem. Should bugreport be closed?