Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Database not saved when form (or report) is saved|
|Component:||code||Assignee:||AOO issues mailing list <issues>|
|Status:||CONFIRMED ---||QA Contact:|
|Priority:||P3||CC:||bettina.haberer, issues, mechtilde, nesshof|
|Version:||OOo 2.3.0 RC1||Keywords:||oooqa, usability|
|Issue Type:||ENHANCEMENT||Latest Confirmation in:||---|
Description aexl 2007-06-17 13:04:49 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.
Comment 1 christoph.lukasiak 2007-09-03 12:18:40 UTC
works fine for me in a OOg680m3
Comment 2 christoph.lukasiak 2007-09-03 12:21:23 UTC
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
Comment 3 aexl 2007-09-03 12:46:43 UTC
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.
Comment 4 aexl 2007-09-06 14:19:46 UTC
Tested this in 2.3RC1.(OOg680m3) Still exists. Can you reopen or do you need more info?
Comment 5 Mechtilde 2007-09-06 14:52:46 UTC
works also for me on debian in OOG680_m4 = RC2
Comment 6 aexl 2007-09-06 15:02:12 UTC
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.
Comment 7 Mechtilde 2007-09-08 22:21:46 UTC
that means, that it doesn't crash
Comment 8 aexl 2007-09-10 10:05:26 UTC
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")
Comment 9 Mechtilde 2008-01-23 21:23:23 UTC
Comment 10 aexl 2008-01-25 10:19:08 UTC
mechtilde, did you READ my last comment? should i re-file a new issue?
Comment 11 Mechtilde 2008-02-03 13:22:11 UTC
Yes I can confirm it now with OOH_m5 I had a crash and lost my work on RPT
Comment 12 christoph.lukasiak 2008-06-17 17:12:32 UTC
does it still occur in a current version?
Comment 13 christoph.lukasiak 2008-06-17 17:14:03 UTC
clu->mechtilde: if yes, please send further to oj
Comment 14 Mechtilde 2008-06-18 12:34:06 UTC
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
Comment 15 Martin Hollmichel 2008-08-27 13:57:56 UTC
this looks like a major flaw in the workflow with potential dataloss. set target to 3.1, set keyword usability.
Comment 16 Frank Schönheit 2008-08-27 14:07:33 UTC
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.