Apache OpenOffice (AOO) Bugzilla – Issue 78574
Database not saved when form (or report) is saved
Last modified: 2013-08-07 15:45:09 UTC
Steps: 1. open database 2. change report 3. click on "save" in report window 4. let OO crash =:-() Result: lose hours of work Expected: save your work. this only happens when doing a "save" in the db window immediately after step 3. Proposed fix: db save should be done automatically after i save a report or form.
works fine for me in a OOg680m3
clu->aexl: 1. does it still happen? (is it reproducable) 2. may you try it in current version available here: http://download.openoffice.org/680/index.html thx
yes this is always reproducible here. just tested it with a form: changed the form, saved it, but the odb file was not touched and "save" button in main window changed to active. using 2.2.0 on ubuntu which says it is OOF680_m14 Build 1. testing a current version i do not dare on my production pc. you really cannot reproduce? i might reopen it if it lasts in a productive 2.3 version.
Tested this in 2.3RC1.(OOg680m3) Still exists. Can you reopen or do you need more info?
works also for me on debian in OOG680_m4 = RC2
may i ask what worksforme means? does it mean you cannot reproduce my bugreport (this might mean there is a misunderstanding or i did not clarify the thing enough) OR does it mean you can reproduce but dont see any problem in this ("its not a bug, its a feature" ;-) to say it in other words: the bug is about: when you "save" a DB form it is only saved in memory, not to the odb file on disk.
that means, that it doesn't crash
oh, that was the misunderstanding: no, it does not necessarily crash. but *if* it crashes ("4. *let* it crash") everything is lost. i apol9ogize and here a better *description*: Steps: 1. open database 2. change report 3. click on "save" in report window Result: form is saved "in memory", odb file is not touched. this only happens when doing a "save" in the main db window. Expected result: odb save should be done automatically after i save a report or form or query. is it is, there is the risk to lose hours of work in case OOo crashes. (which happened several times to my users and they just wont understand "why do i have to save twice in order to save a form")
-> closed
mechtilde, did you READ my last comment? should i re-file a new issue?
Yes I can confirm it now with OOH_m5 I had a crash and lost my work on RPT
does it still occur in a current version?
clu->mechtilde: if yes, please send further to oj
hello Ocke, The problem is that it is not enough to save a changed form or report but you have to save also in the database browser. If you don't do the last step you can lost your work although you save from or report. Mechtilde
this looks like a major flaw in the workflow with potential dataloss. set target to 3.1, set keyword usability.
No, it isn't a "major flaw", it was intentionally introduced this way back when we designed the application, for various reasons. See below for details. As a preliminary note: Please note that OpenOffice.org's way to prevent data loss through crashes is the crash recovery. If that would work with forms/reports, too (which it currently doesn't), the the a major foundation of the issue ("4. let OOo crash; Result: lost hours of work") would vanish. Unfortunately, there's no resources in the framework team to fix the auto recovery process so it also works with database documents, so ... Now for the reasons why it is as it is: Since .odbs use ZIP containers as storage format (as it is dictated by the ODF format we us), an attempt to save the complete document is potentially expensive: It implies that we need to store *all* parts of the document, again - all forms, all reports, plus the contained data. For a sufficiently large number of sub documents, and, more important, for a sufficiently large data set in the DB, this is an expensive operation. Note, that here "large" data set means something starting with 10 MB or so, which isn't really much data for real life use cases. If we would save the complete DB doc with every save of a form/report/table design/query design/relation design/layout change (the latter being things like simply changing the with of a column in the table data view), then this will potentially buy us severe performance problems. It's worth investigating how severe those problems are, but "Just Do It" is not the right way here, IMO.
*** Issue 96760 has been marked as a duplicate of this issue. ***