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: Not Assigned
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-08-30 13:20 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 (CIB) 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 (CIB) 2018-01-31 13:28:19 UTC
...it's the OBookmarkContainer change in dbaccess/source/core/dataaccess/datasource.hxx/.cxx...
Comment 5 Michael Stahl (CIB) 2018-01-31 13:30:59 UTC
hahaha...

void SAL_CALL OBookmarkContainer::acquire(  ) throw()
{
    m_rParent.acquire();
}
Comment 6 Michael Stahl (CIB) 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.
Comment 13 Xisco Faulí 2018-07-04 11:19:49 UTC
I can't reproduce it in

Version: 6.2.0.0.alpha0+
Build ID: 5fce97a58b8f764e35bf98128591c9a89537da05
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded

@Robert,
Could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/ ?
You can install it alongside the standard version.
Comment 14 robert 2018-07-04 14:16:24 UTC
(In reply to Xisco Faulí from comment #13)
> 
> @Robert,
> Could you please try to reproduce it with a master build from
> http://dev-builds.libreoffice.org/daily/master/ ?
> You can install it alongside the standard version.

Have tested with
Version: 6.2.0.0.alpha0+
Build ID: 585415df64f226503b52d1e2b7971a9c46eb6917
CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: kde4; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-07-04_01:59:25
Locale: de-DE (de_DE.UTF-8); Calc: group threaded
on OpenSUSE 42.3 64bit rpm Linux

Data aren't saved. When closing LO LO crashes. Reproduced this crash every time, after three new starts the connection to the database is lost. Have tried to setup the connection but this wasn't saved.

The tested dev-build is unusual for working with external forms and internal database. Could be there is another problem with switching the database from HSQLDB to Firebird ...
Comment 15 Xisco Faulí 2018-07-04 14:18:11 UTC
oh, so you migrated the ddbb?
Could you please try without migrating the ddbb ?
Comment 16 robert 2018-07-04 14:28:34 UTC
First test I made without migrating the database to Firebird. Doesn't work. Then  I
have tried it also with the same database, changed to Firebird-database. Data in the form could only be entered when database-connection is declared new (couldn't be saved). Data seem to be saved in the form. After saving the form and closing LO LO crashes. Reopening LO and looking for the data in the *.odb-file: No data have been saved. It's the same behavior with internal Firebird as before with internal HSQLDB.
Comment 17 Michael Stahl (CIB) 2018-08-30 13:20:32 UTC
don't have time to investigate this further now...