Download it now!
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)
Version:
(earliest affected)
3.6.0.4 release
Hardware: x86 (IA32) Linux (All)
: medium major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
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:


Attachments

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?

@Roman:
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 3.6.0.4 rc  German UI/Locale [Build-ID:  932b512] on German WIN7 Home Premium (64bit).

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

@robert@familiegrosskopf.de:
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:
https://bugs.freedesktop.org/show_bug.cgi?id=52639#c20
Its the same behaviour with the wizards and the report-builder - one system fails, the other works.

@Rainer
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 (CIB) 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 ***