Issue 55493 - database data (embedded HSQLDB) lost when OOo crashes
Summary: database data (embedded HSQLDB) lost when OOo crashes
Alias: None
Product: Base
Classification: Application
Component: code (show other issues)
Version: 680m130
Hardware: All All
: P3 Trivial (vote)
Target Milestone: OOo 2.0.1
Assignee: marc.neumann
QA Contact: issues@dba
: 54609 55274 (view as issue list)
Depends on:
Reported: 2005-10-05 11:00 UTC by Frank Schönheit
Modified: 2006-05-31 14:29 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---

document to reproduce the bug case (3.05 KB, application/vnd.sun.xml.base)
2005-10-05 11:39 UTC, Frank Schönheit
no flags Details
document to provoke a crash (7.85 KB, application/vnd.oasis.opendocument.text)
2005-10-05 11:41 UTC, Frank Schönheit
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description Frank Schönheit 2005-10-05 11:00:52 UTC
- open the attached database document
- select "Tables" on the left hand side, and double-click the table "abc"
  to open it for data entry
- enter a new record with arbitrary data
- close the table data view
- open the attached crash.odt
- press the button therein, which provokes a crash
=> the recovery mechanism starts, saying that the database file has been
   saved and will be recovered upon next start
- start OOo again
=> the recovery wizard starts, let it recoover the database document
- open the table "abc"
=> the changes made in the previous session are lost

For a *database*, it's expected that as soon as you write your changes, they're
safe - no matter whether OOo crashs, you unplug your machine, or whatever.

Note that there is also another occurance of this issue:
Normally, if the database document is modified when OOo crashes, the bug does
*not* happen. In this case, the recovery mechanisms recognizes the DB doc as
modified (which it normally isn't when you "only" enter data), stores it when
OOo crashs, and properly restores it upon next recovery.
*However*, if OOo crashs, and the recovery wizard fails for whatever reason,
then the DB data is also lost, no matter if the DB doc was modified or not.

When we created the new Base, we decided that there are two kinds of operations
which a user can do
1. pure data operations, like editing/inserting/deleting data from tables
2. "client-side" operations, like modifying forms, modifying the UI layout
   of tables, and the like
Operations from the first category were declared to not modify the document (in
opposite to operations from the second category), exactly it is absolutely not
expectation-conformant if the user has to *save* changes to her data before they
really become committed. Instead, the expectation for a database is that as soon
as you commit your changes to a certain record, the changed data is persistent,
no matter what happens next.
Comment 1 Frank Schönheit 2005-10-05 11:13:32 UTC
*** Issue 55274 has been marked as a duplicate of this issue. ***
Comment 2 Frank Schönheit 2005-10-05 11:39:56 UTC
Created attachment 30137 [details]
document to reproduce the bug case
Comment 3 Frank Schönheit 2005-10-05 11:41:06 UTC
Created attachment 30138 [details]
document to provoke a crash
Comment 4 Frank Schönheit 2005-10-05 11:41:49 UTC
Comment 5 Frank Schönheit 2005-10-05 12:29:12 UTC
fixed in CWS dba201d

I added a few more places where the changes in the DB data are synced back to
the file. They'er (hopefully) often enough to significantly reduce the chance
for a data loss, and seldom enough to be seriously noticed.

While I acknowledge that this is not a final solution, it's at least a
relaxation of the current situation. A final solution is hard to implement with
the current approach of ZIP files, since they do not allow for O(1) random
access to the whole file, which would be necessary.
Comment 6 Frank Schönheit 2005-10-05 12:29:18 UTC
*** Issue 54609 has been marked as a duplicate of this issue. ***
Comment 7 Frank Schönheit 2005-10-05 12:48:45 UTC
for the record: issue 54609 is about finding a real solution for this issue.
Comment 8 Frank Schönheit 2005-10-11 09:02:37 UTC
fs-> msc: please verify in CWS dba201d

re-open issue and reassign to msc
Comment 9 Frank Schönheit 2005-10-11 09:02:43 UTC
reassign to msc
Comment 10 Frank Schönheit 2005-10-11 09:02:55 UTC
reset resolution to FIXED
Comment 11 marc.neumann 2005-10-20 08:22:27 UTC
verified in cws dba201d
Comment 12 marc.neumann 2005-11-18 10:35:16 UTC

this is fixed in the current master. The current master is available at

I close this issue now.

The issue is not fixed in a patch installation set. I wrote a new Issue 58094
for this 

Bye Marc