To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=108303
------- Additional comments from [email protected] Tue Apr 6 16:43:28 +0000 2010 ------- Mechtilde - I guess you already found, where the small word "not" is missing Just to put the things together: The question was, whether it is possible, to make use of DBF in OOO esp. make reuse of a DBF-field in OOO as prim.Key-field. The test-scenario is quite simple: save the - in OOO altered - DBF and reopen it in the application, where the original DBF is derived from. if it works, all is fine (which is not so!) a) open DBF in in an ODB-Container: works, but ... - put in data in OOO: works - reopen in OOO: works - reopen in DBF-appl.: broken broken because: OOO does not know how to handle "numeric" fields - adds always .00 and kills counter-fields b) - open in ODB and copy to CALC and save as DBF: totally broken (no fixed length, no numeric, none functioning header) c) copy from any DBF from within any OOO-source (ODB or CALC) and paste it to HSQL-File: -copy: works - paste: works partly (see below) - reexport to DBF: broken paste: is working, BUT ... but-1.) No "numeric" field is treated right: DBF-Numeric-N0 == INT DBF-Numeric-N4 == decimal 4 decimal places in NO CASE a dbf-numeric is a OOO-"number(numeric)"-type!! Note: if the DBF-N0 is used as a counter or Autoincr.Prim.Key, OOO actually breaks it in any case, when set to INT aswell as when left as numeric but-2.) a counter-field can be set to be the prime-key, but that's strange - copy DBF - paste DBF to new and correct in the dialog-boxes: --- new ID? No --- add all fields --- change fieldtype of manually selected field to INT --- change that field with right-click to PRIM-KEY -- close and reopen table --- change THAT field to AUTO-INCR --- close table --- open SQL-Window from menue --- put in statement "alter table "tabelle1" alter column "id" restart with 12000" the counter is working (note: it is now(m14) working as it was in m2 - the double-issue from m5 regarding the glitch from changing fields in table-definitions had been partly repaired) d) same as c) - with more than 10 filelds in original DBF-File: - copy: works - paste: broken terminates with "parameter too long" the behaviour to put all requested parameters for to build the new HSQL-table in one string will not work, as it exceeds the allowed length of such parameters. By that, the "workaround-with-special-advise" can not be tested for version d) and is treated as broken. All in all: No good idea to close this issue until some homework is done. Martin --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
