Bug 53115 - EDITING: Wizards destroy *.odb-files
Summary: EDITING: Wizards destroy *.odb-files
Status: RESOLVED DUPLICATE of bug 52639
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
(earliest affected) release
Hardware: x86 (IA32) Linux (All)
: medium major
Assignee: Not Assigned
Depends on:
Reported: 2012-08-04 07:20 UTC by Robert Großkopf
Modified: 2012-08-10 20:15 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Robert Großkopf 2012-08-04 07:20:10 UTC
Same as reported in https://bugs.freedesktop.org/show_bug.cgi?id=52639. When I execute the query-wizard in Base, save the query, close Base and LO and then try to open the database-file again it could not be opened.
I had a look with a pack-programm inide the *.odb-File. META-INF/manifest.xml is a file with 0 Byte.
Same behaviour of the program with the wizard for tables and the wizard for forms. Every wizard destroys the whole *.odb-file!
My System: OpenSuSE 11.4, 32bit-rpm.
For working with databases this program is unusable. We have no bugs to fix for databases, before this bug isn't fixed.
Comment 1 Roman Eisele 2012-08-05 10:18:39 UTC
Corrected Rainer’s mail address (I think he will prefer LibO-related issues mailed to LibreOffice@...).
Comment 2 Rainer Bielefeld Retired 2012-08-05 17:12:35 UTC
Currently we have no confirmation, so NEW and Blocker is wrong

We do not need high priority pickers, but a plausible hypothesis. May be the problem has nothing to do with Database, but with extensions registration (for Bug 52639 I doubt because the problem persists with new user profile, only example) or what ever else?

@Sasha, Robert:
Is this one reproducible for your, too?
Does the problem persist when you rename your user profile? Any info with what version that started?

Thank you for correcting that. I need a second account to test Bugzilla related problems, unfortunately it is too similar to the "normal" one. I will modify that
Comment 3 Robert Großkopf 2012-08-05 19:09:52 UTC
The behaviour is the same as in https://bugs.freedesktop.org/show_bug.cgi?id=52639 . I could restart with a new user-profile - no difference. I haven't any extensions installed - except those, which were added to LO by default. I have checked md5sum of LO-packages.
The wizards are no extensions. But the result is the same: Unsusable database after closing LO.
The following steps I can reproduce every time.
1. Open LO
2. Create DB
3. Choose Wizard for tables or queries or forms 
4. Close wizard - nothing to save.
5. Close Base
6. Reopen the file without closing the whole LO → works
7. Close LO
8. Open LO
9. Open created DB → failed with "General Error"
When you look in the *.odb-file ist the same as reported in the other bug-description: empty META-INF/manifest.xml
Comment 4 Rainer Bielefeld Retired 2012-08-06 05:02:38 UTC
NOT reproducible with Server Installation of  "LibreOffice rc  German UI/Locale [Build-ID:  932b512] on German WIN7 Home Premium (64bit).

0. Launch LibO
   > Start center Appears
1. Button "New Database
  > New Database will be opened, Dialog appears
2. <Next>
4. In new dialog I check "Create Table using the Table Wizard
5.  <Finish>
6. Browse for Folder, Name "MyNewDatabase.odb", <Save>
   > DB will be saved, Table Wizard Dialog Appears
7. <Cancel>
   > Wizard dialog disappears
8. Menu 'File -> Close'
   > Closes DB without asking
9. DB can re opened from Recent Documents without problems

I did the same steps, but between step 7 and 8 I selected Fields "ASSETID" ... 
"DepartmentID" from template "Assets" under "business"  and then finished 
Wizard,  Menu 'File -> Close'. 
Here I see something strange, what might be a separate bug: I have not been asked whether I want to save something, and   'File -> Close' closes the document as it seems without saving. But when I reopen the document, DB contains a table with all fields of template "Assets", not only  "ASSETID" ... "DepartmentID".

I did an additional test with <Finish> after reporter's Step 2, 1 attempt with only open / close wizard, one with Fields "ASSETID" ... "DepartmentID"

Reporter's Problem is not reproducible for me. My manifest.xml always has some contents bigger than 680 bytes.

Your step by step instruction is incomplete, more or less not true, useless! I believe you wrote down some steps you believed to remember, but not the ones you really did. So I have a big uncertainty whether there is some little thing in your proceeding what is different to my proceeding and shows the bug.
Comment 5 Jochen 2012-08-06 06:20:50 UTC
Hi Rainer, *,

the problems don´t occur using Windows as OS, but only using Linux.
You have tested on a Windows-platform.
Comment 6 Robert Großkopf 2012-08-06 07:23:51 UTC
I can't confirm it with the same system and a little difference between the GUI. Have a look here:
Its the same behaviour with the wizards and the report-builder - one system fails, the other works.

In your description it looks as if you choose the table-wizard before the database isn't saved. When I wrote: "2. Create DB" I mean all those with new database, searching for a folder, save. And then I only had to open any wizard and close it again - nothing to do, nothing to save. Closing base, closing LO, opening LO - database could not be opened any more (with my Linux-System at home, and, could be, with sashas system, too.)
Comment 7 Lionel Elie Mamane 2012-08-06 08:43:22 UTC
Cannot reproduce with my development tree (branch libreoffice-3-6 commit 5ea5a0ff387d22e10b7565eec7f0f4abc685dda7 of last week) on Debian GNU/Linux amd64.
Comment 8 Robert Großkopf 2012-08-06 15:52:34 UTC
See https://bugs.freedesktop.org/show_bug.cgi?id=52639#c31 . Seems to be the same reason - only a problem with *.rpm-packages on Linux-systems (Fedora, Redhat, SuSE ...). No windows-problem, no *.deb-problem!
Comment 9 Michael Stahl (allotropia) 2012-08-10 20:15:12 UTC
this is a duplicate of bug 52639

the commit 142d3ec875b446b56d0071c59d00937dea0cdd61
makes the difference in reproducing as per comment #3.

*** This bug has been marked as a duplicate of bug 52639 ***