Bug 114596 - External forms for a database doesn't save data - closing form with dataloss
Summary: External forms for a database doesn't save data - closing form with dataloss
Status: REOPENED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
5.1.0.3 release
Hardware: All All
: medium critical
Assignee: Michael Stahl
URL:
Whiteboard: target:6.1.0 target:6.0.1 target:5.4.6
Keywords: bibisected, bisected, dataLoss, regression
Depends on:
Blocks: Database-Forms
  Show dependency treegraph
 
Reported: 2017-12-20 16:24 UTC by robert
Modified: 2018-05-04 18:17 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Zip-folder with database and external form - see description (17.69 KB, application/zip)
2017-12-20 16:24 UTC, robert
Details

Note You need to log in before you can comment on or make changes to this bug.
Description robert 2017-12-20 16:24:37 UTC
Created attachment 138551 [details]
Zip-folder with database and external form - see description

Extract the attached *.zip-folder.
Enter the database to Tools > Options > Base > Databases (Name: TestDB)
Open the *.odt-file of the folder.
Put data into tho only field for text. 
Switch to next row.
If you switch back you could see the data has got a new AutoValue - all seems fine.
Close the form.
Close LO.
Reopen LO.
Open the database, not the form.
Have a look to the only table of the database.
No new value has been saved.

Have tested this with different versions:
First version which fails here is LO 5.1.0.3, last version I have installed were the bug doesn't appear is LO 5.0.5.2.
This is a regression with critical severity because all data, which seems to be saved, isn't saved (dataloss!!). I am not allowed to set the severity up to this ...

My system: OpenSUSE 42.2 64bit rpm Linux. But bug has also been detected by a user with Windows 10 - so I haven't set Hardware and OS.
Comment 1 F3K Total 2017-12-25 12:26:46 UTC
I can confirm that behaviour, using LO 5.4.3 under Windows 7
Comment 2 robert 2017-12-25 12:35:07 UTC
Following comment1 I will set this bug to NEW.
Comment 3 Michael Stahl 2018-01-31 13:19:14 UTC
master fails
5.0.6.3 works
5.1.0.3 fails
5.1 branch point fails
5.0 branch point works

bibisect range:

71ace488448b64e6c4cd9065e109d2c9850b031a..cd6c9aef7468120dd5ea5c747f35c98baf214613

regression from:

commit 2660d24a07866e083c5135ea263030f3e3a2e729
Author:     Noel Grandin <noel@peralex.com>
AuthorDate: Mon Jul 13 16:17:00 2015 +0200

    new loplugin: refcounting
    
    This was a feature requested by mmeeks, as a result of
    tdf#92611.
    
    It validates that things that extend XInterface are not
    directly heap/stack-allocated, but have their lifecycle managed
    via css::uno::Reference or rtl::Reference.
Comment 4 Michael Stahl 2018-01-31 13:28:19 UTC
...it's the OBookmarkContainer change in dbaccess/source/core/dataaccess/datasource.hxx/.cxx...
Comment 5 Michael Stahl 2018-01-31 13:30:59 UTC
hahaha...

void SAL_CALL OBookmarkContainer::acquire(  ) throw()
{
    m_rParent.acquire();
}
Comment 6 Michael Stahl 2018-01-31 13:41:10 UTC
fixed on master.
Comment 7 Commit Notification 2018-01-31 13:41:22 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=96ae2a3300811897c24cccb20f8c2faf382483df

tdf#114596 dbaccess: fix mysterious dataloss bug

It will be available in 6.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 8 Commit Notification 2018-01-31 16:56:38 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=e80da60895b45309fa1d018760d5f11cca4367f4

tdf#114596 compilerplugins: add exception to [loplugin:refcounting]

It will be available in 6.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 9 Commit Notification 2018-02-01 09:10:52 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-6-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=66baf6cf11e333936a4404d3a02d44a19e6a440c&h=libreoffice-6-0

tdf#114596 dbaccess: fix mysterious dataloss bug

It will be available in 6.0.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 10 Commit Notification 2018-02-01 15:48:24 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-5-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=b5440ce23b17d84f7971cb7ea35512d5cac69c9f&h=libreoffice-5-4

tdf#114596 dbaccess: fix mysterious dataloss bug

It will be available in 5.4.6.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 11 ge60 2018-04-29 12:21:14 UTC
Problem is still alive in LO 5.4.6.2 (official version, no daily build).

I use a write-protected stand-alone form (odt) originally created in LO 4 with a connection to a query to a registered database. The data is shown via a form-based filter. Data changes are confirmed by a user-button within the form. When i  move to the next data record and back again, the modified data is shown, so the record seems to be stored. But when i close and then re-open the form, the original data is shown, the changes are lost.

My last version that worked: 5.1.1
Error occurred with: 5.3.7
Error still there after update to 5.4.6.2

The file date of the odb file still corresponded to the last changes made under LO 5.1.1

After forum search, i tried the work-around from F3K Total (event macro "after record action", https://www.libreoffice-forum.de/viewtopic.php?f=10&t=18340). This worked.

Operating system: windows 10 (currently 1709 Build 16299.371)

Robert advised me to add this comment here, i don't know if i should change the bug status
Comment 12 robert 2018-05-04 18:17:46 UTC
Could confirm the buggy behavior hasn't gone.
Tested with
Version: 6.0.3.2
Build-ID: 8f48d515416608e3a835360314dac7e47fd0b821
CPU-Threads: 4; BS: Linux 4.4; UI-Render: Standard; VCL: kde4; 
Gebietsschema: de-DE (de_DE.UTF-8); Calc: group

Opened the form of the attachment.
Set the connection to the database (remark: Save the folder, but don't save it again after input of data - connection will be lost, see bug 117261).
Input new data.
Scroll forward to next row.
Scroll back: Data are there.
Close the form (don't press save - the connection will be lost! - has nothimng to do with saving of data).
Close LO.
Open LO. 
Open the form - the new input isn't there.

I will Reopen the bug.