Issue 78574

Summary: Database not saved when form (or report) is saved
Product: Base Reporter: aexl <openoffice>
Component: codeAssignee: AOO issues mailing list <issues>
Status: CONFIRMED --- QA Contact:
Severity: Trivial    
Priority: P3 CC: bettina.haberer, issues, mechtilde, nesshof
Version: OOo 2.3.0 RC1Keywords: oooqa, usability
Target Milestone: ---   
Hardware: All   
OS: All   
Issue Type: ENHANCEMENT Latest Confirmation in: ---
Developer Difficulty: ---

Description aexl 2007-06-17 13:04:49 UTC
1. open database
2. change report
3. click on "save" in report window
4. let OO crash =:-()

lose hours of work 

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

1. does it still happen? (is it reproducable)
2. may you try it in current version available here:

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)
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*:

1. open database
2. change report
3. click on "save" in report window

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
-> closed
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.

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'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.
Comment 17 ocke.janssen 2009-01-21 12:32:11 UTC
*** Issue 96760 has been marked as a duplicate of this issue. ***