Bug 112458 - Base table does not retain record updates from Standalone form
Summary: Base table does not retain record updates from Standalone form
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
5.1.0.3 release
Hardware: x86-64 (AMD64) Linux (All)
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, regression
Depends on:
Blocks:
 
Reported: 2017-09-17 21:36 UTC by Stang
Modified: 2019-05-07 17:05 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Database table for test (12.19 KB, application/vnd.oasis.opendocument.database)
2017-09-17 21:37 UTC, Stang
Details
Standalone Form for Test (11.19 KB, application/vnd.oasis.opendocument.text)
2017-09-17 21:38 UTC, Stang
Details
bibisect in till51 repo, tail of terminal output (2.24 KB, text/plain)
2018-12-02 01:27 UTC, Terrence Enger
Details
bibisect in till53 repo, tail of terminal output (2.41 KB, text/plain)
2018-12-03 04:41 UTC, Terrence Enger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stang 2017-09-17 21:36:14 UTC
Description:
When using a standalone form for Base, any add, change or delete seems to work.  Changes made are visible when records scrolled through.  When the form is closed & re-opened, the changes are gone.

Steps to Reproduce:
1.Open standalone form
2.Add, change or delete record(s)
3.close then re-open form

Actual Results:  
Changes gone.

Expected Results:
Retain changes.


Reproducible: Always

User Profile Reset: No

Additional Info:
If the standalone form is opened and changes made, and before closing the form the .odb is opened & table data is viewed (nothing more) and then all closed, the modifications are retained.  Without doing this all changes are lost.

This did work on v5.2.5.1

Tested with daily and did not work:

Version: 5.4.2.0.0+
Build ID: 61d85c4e7c30ea0f5242d927b7456190020b4fbe
CPU threads: 4; OS: Linux 4.8; UI render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:libreoffice-5-4, Time: 2017-09-15_12:00:43
Locale: en-US (en_US.UTF-8); Calc: group

Samples attached: Customers.odb (need to register); CustomersEntry.odt (set for Customers registered name)


User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.91 Safari/537.36
Comment 1 Stang 2017-09-17 21:37:44 UTC
Created attachment 136320 [details]
Database table for test
Comment 2 Stang 2017-09-17 21:38:17 UTC
Created attachment 136321 [details]
Standalone Form for Test
Comment 3 Alex Thurgood 2017-09-18 06:31:25 UTC
No repro

Version: 5.4.1.2
Build ID: ea7cb86e6eeb2bf3a5af73a8f7777ac570321527
CPU threads: 4; OS: Mac OS X 10.12.6; UI render: default; 
Locale: fr-FR (fr_FR.UTF-8); Calc: group


I didn't even need to register the database.
Open the standalone form.
Activate Form Design mode.
Right mouse button click to bring up Form properties, choose Data tab.
Indicate datasource (path to ODB), and table (Customers), close the properties dialog, then save the ODT file.
Leave Form design mode to switch back to data entry mode.
Add a new record via the form.
Use the back arrow to move back to a previous record, thereby validating new record data entry.
Save the form before closing.
Open the ODB file. See that the newly entered data appears in the table.
Comment 4 Stang 2017-09-18 15:45:51 UTC
System using Mint18.2:

Version: 5.4.1.2
Build ID: ea7cb86e6eeb2bf3a5af73a8f7777ac570321527
CPU threads: 4; OS: Linux 4.8; UI render: default; VCL: gtk2; 
Locale: en-US (en_US.UTF-8); Calc: group

regardless of using registered name or path to .odb  the record is NOT saved.  Checking multiple LO versions back this is true until I get to v5.2.5.1 and then it is working.

Just reran using your step-by-step process.
Comment 5 Robert Großkopf 2017-09-18 18:53:10 UTC
Could reproduce the buggy behavior with LO 5.4.1.2 on OpenSUSE 42.2 64bit rpm Linux.
Have registered the database as "Customer".
Could input a new row. 
Moved to next row. This should work.
Also pressed the button "Save" of the navigationbar.
Closed the database and switched to LO-Desktop.
Reopened the database: Data could be read, 
but ...
When I close the whole LO and the reopen the new data have been gone.
The standalone-form doesn't work right.

Don't know why the Save-button of the writer-document will save something, but this won't have any effect.

Note: When only opening the database Customers.odb before closing the whole LO the data will appear and will be saved.
Comment 6 Robert Großkopf 2017-09-18 19:06:25 UTC
Have tested a little bit more:
Last installed version where the whole content of the form will be saved without opening database afterwords is LO 5.0.5.2.
Could reproduce the buggy behavior with LO 5.1.0.3 and all newer versions, also 5.1.5.*, 5.2.0.*, 5.2.5.* ...

I will set this bug to the oldest version where the bug appears.
I would also prefer to set the Importance to high and major, because of dataloss, but I have no permission to do this.
Comment 7 Julien Nabet 2017-09-23 21:13:26 UTC
On pc Debian x86-64 with master sources updated yesterday, I noticed this on console during my tests:
warn:legacy.osl:5792:5792:dbaccess/source/core/dataaccess/ModelImpl.cxx:903: DBG_UNHANDLED_EXCEPTION in static bool dbaccess::ODatabaseModelImpl::commitStorageIfWriteable_ignoreErrors(const com::sun::star::uno::Reference<com::sun::star::embed::XStorage>&)
    type: com.sun.star.uno.DeploymentException
    message: component context fails to supply service com.sun.star.io.TempFile of type com.sun.star.io.XTempFile
    context: N4cppu16ComponentContextE
but it's not clear to me when the save must be done.
I can't help here.
Comment 8 Stang 2017-11-20 02:08:19 UTC
I have come up with a work around.  If the database is split then the standalone works.  The problem only seems to occur when using embedded DB.
Comment 9 QA Administrators 2018-11-21 03:44:44 UTC Comment hidden (obsolete)
Comment 10 Robert Großkopf 2018-11-21 15:44:16 UTC
Bug still exists in LO 6.1.3.2., OpenSUSE 15, 64bit rpm Linux. Standalone forms are unusable with this bug!

You could work around this with
---------
Sub S_FLUSH(EVENT)
    EVENT.SOURCE.ACTIVECONNECTION.flush
End Sub
---------
Start this "After record action" and the data will be saved.
Comment 11 Terrence Enger 2018-12-02 01:27:30 UTC
Created attachment 147213 [details]
bibisect in till51 repo, tail of terminal output

Working on debian-buster in the daily till51 bibisect repository, I
see that the bug came into LibreOffice sometime in the 53 or so
commits:

          commit    date        s-h
          --------  ----------  --------
    good  567a8477  2015-08-03  71ace488
    bad   b6f9394f  2015-08-04  cd6c9aef

which is to say
<https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=71ace488..cd6c9aef>

I am removing key bibisectRequest and adding bibisected.
Comment 12 Lionel Elie Mamane 2018-12-02 07:27:45 UTC
(In reply to Terrence Enger from comment #11)

> (...) I see that the bug came into LibreOffice sometime in
> the 53 or so commits:

> <https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=71ace488..
> cd6c9aef>

From looking at these commits, a prime suspect is:
https://cgit.freedesktop.org/libreoffice/core/commit/?id=2660d24a07866e083c5135ea263030f3e3a2e729

since it touches lifecycle management... Maybe the data source is not any more destroyed, or destroyed at a different time? The debug message in comment 7 looks relevant.

Other commits that touch database stuff is
https://cgit.freedesktop.org/libreoffice/core/commit/?id=7339c360ef55fdde99907e1e34a231386ebc534e
and its followup
https://cgit.freedesktop.org/libreoffice/core/commit/?id=37ec6cbeebc5dc9bf642eedcf45f0441edd3d610

But, true, the bug may come from outside database code altogether, so theoretically possible a sw or sc change is responsible.
Comment 13 Lionel Elie Mamane 2018-12-02 07:31:16 UTC
(In reply to robert from comment #10)
> You could work around this with
> ---------
> Sub S_FLUSH(EVENT)
>     EVENT.SOURCE.ACTIVECONNECTION.flush
> End Sub
> ---------
> Start this "After record action" and the data will be saved.

This looks like either the standalone form doesn't flush the connection when it is being closed, _or_ it tries, but that fails (because the connection is already destroyed?), _or_ the connection doesn't correctly flush itself when it is being closed (comment 7 could be relevant there), _or_ the connection is never closed / closed at the wrong moment (which brings us back to lifecycle management).
Comment 14 Lionel Elie Mamane 2018-12-02 07:32:07 UTC
(In reply to Stang from comment #8)
> I have come up with a work around.  If the database is split then the
> standalone works.  The problem only seems to occur when using embedded DB.

Hmm... Does it work with an embedded Firebird database, or is the bug also present there?
Comment 15 Robert Großkopf 2018-12-02 08:17:30 UTC
(In reply to Lionel Elie Mamane from comment #14)
> (In reply to Stang from comment #8)
> > I have come up with a work around.  If the database is split then the
> > standalone works.  The problem only seems to occur when using embedded DB.
> 
> Hmm... Does it work with an embedded Firebird database, or is the bug also
> present there?

No, doesn't work with embedded Firebird. Have just migrated a database for a standalone form. Data weren't saved after closing the form and LO.
Comment 16 Terrence Enger 2018-12-02 13:42:04 UTC
(In reply to Lionel Elie Mamane from comment #13)
> This looks like either the standalone form doesn't flush the connection when
> it is being closed, _or_ it tries, but that fails (because the connection is
> already destroyed?), _or_ the connection doesn't correctly flush itself when
> it is being closed (comment 7 could be relevant there), _or_ the connection
> is never closed / closed at the wrong moment (which brings us back to
> lifecycle management).

Funnily enough, the change _persists_ if you close LibreOffice from
the form.  The change is _lost_ if you close the form window and then
close LibreOffice from Start Center.
Comment 17 Robert Großkopf 2018-12-02 15:58:39 UTC
(In reply to Terrence Enger from comment #16)
> 
> Funnily enough, the change _persists_ if you close LibreOffice from
> the form.  The change is _lost_ if you close the form window and then
> close LibreOffice from Start Center.

Couldn't confirm that there is any difference. If you haven't opened the database-file itself, the behaviour is always the same: Data were lost.
- Direct closing LO directly.
- Closing the external form, then LO.
When closing the external form, reopen the form there is a difference between HSQLDB and Firebird: HSQLDB shows the new entries, but looses these entries if you close sometimes LO. Firebird doesn't show any new entry.
Seems database has been shut down complete for Firebird when closing the form, but will be shut down for HSQLDB when closing LO.
Comment 18 Terrence Enger 2018-12-03 04:41:03 UTC
Created attachment 147232 [details]
bibisect in till53 repo, tail of terminal output

I now think I see that behaviour deteriorated in two steps:

(1) To close LibreOffice directly from the form loses changes, but
    changes persist after closing the form window and then closing
    LibreOffice from Start Center.  Comment 11 reports my results
    bibisecting this problem.

(2) Additionally, to close the form window and then closing
    LibreOffice from Start Center loses change.  This is what robert
    reports in comment 17.

Working on debian-buster in the till53 bibisect repository, I see that
bug (2) entered LibreOffice in the 57 or so source commits
<https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=8bfbd7fb..e2f6c7f0>.

To summarize:

    changes ...                   commit    date        s-h
    ----------------------------  --------  ----------  --------
    persist                       567a8477  2015-08-03  71ace488
    persist if close LO directly  b6f9394f  2015-08-04  cd6c9aef
    persist if close LO directly  8bb36bab  2016-10-10  8bfbd7fb
    lost either way               49fe466f  2016-10-11  e2f6c7f0
Comment 19 Tony 2019-01-30 17:09:36 UTC
With version 6.1.2.1 on MacOS Mojave (10.14) this bug now also shows using standalone ODT form and an ODB database. In all previous version it was not there and the combination worked well.
Unfortunately I cannot tell whether the OSX update or the LibreOfice update caused the change in behavior.
Comment 20 Noel Grandin 2019-01-31 16:08:02 UTC
When I try to test this in a current master build, all of the "new record", "save record", etc, buttons on the document are disabled?

what am I doing wrong?
Comment 21 Noel Grandin 2019-01-31 16:48:44 UTC
I'm guessing I'm missing a step like 'register the database'? clearly just putting the form document and the ODB file in the same folder, and then opening the form document does not work :-(
Comment 22 Robert Großkopf 2019-01-31 19:11:33 UTC
(In reply to Noel Grandin from comment #21)
> I'm guessing I'm missing a step like 'register the database'? clearly just
> putting the form document and the ODB file in the same folder, and then
> opening the form document does not work :-(

If you are trying to reproduce the bug with the example database, you have to register the database as "Customer".
(See comment 5)
Comment 23 tomek 2019-03-05 13:44:42 UTC
The same bug appars on 6.2.0.3
Comment 24 Alex Thurgood 2019-04-21 08:54:01 UTC
(In reply to Terrence Enger from comment #18)


> 
> Working on debian-buster in the till53 bibisect repository, I see that
> bug (2) entered LibreOffice in the 57 or so source commits
> <https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=8bfbd7fb..
> e2f6c7f0>.
> 

Of those, I see :

https://cgit.freedesktop.org/libreoffice/core/commit/?id=ecec5524476448d35dd24c5594c2fcbb1a8b6218

and possibly :

https://cgit.freedesktop.org/libreoffice/core/commit/?id=6d9f07d53e9f89b5286637113198e61149a5c771

as being potential candidates, although the first would be my prime suspect...as it appears to allow closure of frames if it can't find a parent UNO context, and I 
 seem to recall that standalone forms don't have that parent frame context unless the ODB file is also loaded in memory...