I have DBF-File open in Calc Procedure works as expected: Copying records in calc an insert them in Base as new will insert a new Base-table. Problem: Fields formated as text, which are blank (have no content), are displayed correct in CALC (empty), but than are imported wrongly to Base (are filled with an unknown letters) Martin
Hi Martin, It could be also best to attach sample files here. If I understand it correctly, we may have 3 files involved: 1. the dbf 2. the ods working fine 3. the odb (containing a table revealing the issue) (In reply to comment #0) > Problem: > Fields formated as text, which are blank (have no content), are displayed > correct in CALC (empty), but than are imported wrongly to Base (are filled with > an unknown letters) So Let me confirm the issue is: Blank fields are shown as garbage characters after copy records via Calc in an odf to Base. Right?
I can't reproduce this buggy behaviour on Mac OSX with LibO RC2. I tried to reproduce with two DBF tables, both of which can be found in the git source, TT_Forms and TT_Query1. Both of these tables have text fields. I opened the tables in Calc, deleted some of the text content, re-saved, then opened again and copied all of the data from each table into a new table in a test HSQLDB database. The copy wizard that starts when you use the context menu "Paste" in the list of tables of the main ODB window lets you choose whether to add just the data or the definitions and the data. I chose "Definitions and Data". It worked just fine. The blank, or null values of the DBF file showed just fine in the newly created ODB db table. Perhaps the text fields that the original poster is using are some kind of special memo field, or longvarchar ? There used to be a bug in DBF files created a long time ago in StarOffice (5.0, 5.1 or 5.2) that caused all memo fields to display as binary strings when copied into a HSQLDB database. I don't remember why that was the case. However, these could be recovered by using a HEX to ASCII converter. As the original poster hasn't yet provided a sample DBF file for us to try out, it is going to be difficult to reproduce. Alex
Hello Alex firstly the O.P. likes to know, whether you have any application at hand, able to deal with original DBF-files in any manner? Open / work / close / reopen / that does work only within OO/LO (CALC or BASE), not when files are reused/reopend with DOS-applications relaying on well-formed DBF-files. no, it is normal text, and I do not understand what you mean by longchar, or by MEMOs (they are not part of the DBF but of the dbt-files) or by ODF-file? It just looks, that Base can not deal with DBF-fields having no content (content-length-pointer = 0) when the field-content character-value is really 00h and not any other from prior content. mh
Hi, Could you post us a sample DBF file then so we can test ? And yes, I could probably dig up a DBF manipulator / creator that wouldn't use SO/OO/NeoO/LibO :-)) Just another thought though, which version of DBF is it ? Did it work properly in OOo at all (any version past or present) ? Alex
Created attachment 41899 [details] DBF-sample with various fields
Hello Actually I can not reproduce the error of the OP, I willtry later. however, attached you find a sample DBF for your guidance. character-encoding/decoding (US 437) is working, the delimiter too, but the detection for decimals, length and tailing figures behind decimal-dot are detectect wrong (counter has tailing zero's!), aswell as the field-labels need manual fix, and additional Prim.Key is exported wrong. Give it a try for youself. Martin
Hello, I can't reproduce this bug with LibO 3.4rc2 on Windows 7 SP1. I used the DPARA1O5.DBF file. I created a new table with choosing 'Définition and data'. It works fine. Bernard
@ ribotb would you mind to drop a copy of your dbf in here ? thx m.
What is the current status for this bug with 3.4.3?
I tested the provided file on LO 3.5 from master : LibO-dev 3.5.0 Build ID: 6058133-1b94742-3dca5fd-7252360 and had no problems either opening it in LO Calc, saving as ODS and then copying the ODS into a hsql ODB file. The data appeared to be imported correctly. Alex
for your guidance: - the error of the original post vanished - no phantasy-bytes in empty fields However - dbf-import to CALC PARTLY correct Import of identifier-fields (label,N,8,0) still overrolled by LO-defaults(label,N,19,2), which means displayed wrong (adding tailing 0-decimals) and saved wrong (dito) Moving to Base: -- Copy that from CALC to BASE impossible, DBF not detected, will take formating stuff as label (eg. NOT "label" but "label,N,19,2") - DBF can be opend, when connection-type is DBF and the source in the proper DBF-collecting-directory - copy to connection-type HSQL does not work -- the working of -- since direct export from ODB fto DBF is not possible, tables need to be copied to CALC, but tables with driver HSQL can not be "saved as" DBF, since for those tables adds always "self-generated" useless labels (N1 to Nn) and no proper DBF-header - seems to work only when the connection-type is DBase. (btw: Export is always greyed out here) -- did I mention, that the special properties dialog does not exist in LO? So all that settings can not be disabled (e.g. dealing with tables with So actually no chance to deal with DBF under LO. m.
Closing due to Comment 11 @mhonline For your problems listed in a.m. Comments you should open a new Bug report, currently I can't see whether we have a bug or a new feature required.