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