Bug 114596 - External forms for a database doesn't save data - closing form with dataloss ( see comment 30 )
Summary: External forms for a database doesn't save data - closing form with dataloss ...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
5.1.0.3 release
Hardware: All All
: high critical
Assignee: Xisco Faulí
URL:
Whiteboard: target:6.1.0 target:6.0.1 target:5.4....
Keywords: bibisected, bisected, dataLoss, regression
Depends on:
Blocks: Database-Forms
  Show dependency treegraph
 
Reported: 2017-12-20 16:24 UTC by Robert Großkopf
Modified: 2019-11-11 11:08 UTC (History)
7 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 Großkopf
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Großkopf 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 Großkopf 2017-12-25 12:35:07 UTC
Following comment1 I will set this bug to NEW.
Comment 3 Michael Stahl (allotropia) 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 (allotropia) 2018-01-31 13:28:19 UTC
...it's the OBookmarkContainer change in dbaccess/source/core/dataaccess/datasource.hxx/.cxx...
Comment 5 Michael Stahl (allotropia) 2018-01-31 13:30:59 UTC
hahaha...

void SAL_CALL OBookmarkContainer::acquire(  ) throw()
{
    m_rParent.acquire();
}
Comment 6 Michael Stahl (allotropia) 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 Großkopf 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 Großkopf 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 Großkopf 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 (allotropia) 2018-08-30 13:20:32 UTC
don't have time to investigate this further now...
Comment 18 sleeve98 2018-11-01 20:27:36 UTC
Confirmed:  Win10, LO 6.0.5.2 x64
BuildID: 54c8cbb85f300ac59db32fe8a675ff7683cd5a16

Same issue connecting external Writer form to HSQLDB-embedded .odb - data not displayed on reopening of document.  Issue presents only intermittently, but > 90% of the time, with no time to test what provokes success or failure (am suspicious of the fact Writer wants to save "changes" to the Read-Only form on exiting, but cannot positively tie this phenomenon to the issue - will try to test...).

Can also confirm that on > 12 machines running 2 OS'es (+ LO 5.x.x), at no time was this issue ever seen with external Writer forms connecting to a "registered" .odb with an SQLite database via ODBC, so that may be a clue.
Comment 19 sleeve98 2018-11-01 20:44:46 UTC
"am suspicious of the fact Writer wants to save "changes" to the Read-Only form on exiting, but cannot positively tie this phenomenon to the issue - will try to test...)"

Found a few minutes - whether Writer document is saved on exit makes no difference; either way data entered "saved" is lost on exit & reopen.  Sorry.
Comment 20 Alex Thurgood 2018-11-07 09:31:47 UTC
(In reply to sleeve98 from comment #18)
> Confirmed:  Win10, LO 6.0.5.2 x64
> BuildID: 54c8cbb85f300ac59db32fe8a675ff7683cd5a16
> 
> Same issue connecting external Writer form to HSQLDB-embedded .odb - data
> not displayed on reopening of document.  Issue presents only intermittently,
> but > 90% of the time, with no time to test what provokes success or failure
> (am suspicious of the fact Writer wants to save "changes" to the Read-Only
> form on exiting, but cannot positively tie this phenomenon to the issue -
> will try to test...).
> 

If the external ODT form file has read-only permissions set, this question always used to get presented to the user on closing the form, at least with OpenOffice.org, as it was a major user interaction PITA.
Comment 21 sleeve98 2018-12-12 19:29:35 UTC
This is absolutely a data validation issue.  For us it was the date fields - once buttoned up, issue resolved.
Comment 22 Julien Nabet 2019-03-10 12:33:37 UTC
On pc Debian x86-64 with master sources updated today, I could reproduce this.

There are always these logs when closing LO after using odb file but not specific to this case:
warn:dbaccess:18597:18597:dbaccess/source/core/dataaccess/ModelImpl.cxx:849: DBG_UNHANDLED_EXCEPTION in static bool dbaccess::ODatabaseModelImpl::commitStorageIfWriteable_ignoreErrors(const com::sun::star::uno::Reference<com::sun::star::embed::XStorage>&) exception: 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: cppu::ComponentContext
warn:dbaccess:18597:18597:dbaccess/source/core/dataaccess/ModelImpl.cxx:753: ODatabaseModelImpl::commitRootStorage: could not commit the storage!
Comment 23 Xisco Faulí 2019-05-17 13:19:13 UTC
In master this problem is blocked by bug 125339
Comment 24 Xisco Faulí 2019-05-23 08:59:18 UTC
(In reply to Xisco Faulí from comment #23)
> In master this problem is blocked by bug 125339

Now it's fixed.
I can reproduce the original problem in

Version: 6.3.0.0.alpha1+
Build ID: e7fb44b8c86b4dce1d4c6f15752cc3bf62b14888
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
Calc: threaded

and

Version: 6.1.0.0.alpha1+
Build ID: 3a801799536e6870f2fb111b1cc00b9575a35a39
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group
Comment 25 Xisco Faulí 2019-05-23 09:00:31 UTC
Just to be clear, the new entry is saved if I open the ddbb without closing LibreOffice but it's gone if I close LibreOffice and then I open the ddbb
Comment 26 Robert Großkopf 2019-05-23 13:52:20 UTC
(In reply to Xisco Faulí from comment #25)
> Just to be clear, the new entry is saved if I open the ddbb without closing
> LibreOffice but it's gone if I close LibreOffice and then I open the ddbb

Yes, if you open the *.odb-file before closing the form the data will be saved. 

The data wont be submitted to the database if the database-file isn't opened.

If adding this to the form after record-change it will work without opened *.odb.

Sub S_FLUSH(EVENT)
    EVENT.SOURCE.ACTIVECONNECTION.flush
End Sub
Comment 27 Xisco Faulí 2019-05-23 23:16:56 UTC Comment hidden (obsolete)
Comment 28 Xisco Faulí 2019-05-23 23:24:16 UTC
I've reverted the commit locally and the issue is fixed. It's important to close LibreOffice without closing the document first. If the document is closed first and later LibreOffice the entry is not saved, but that seems to be another issue
Comment 29 Xisco Faulí 2019-05-28 07:36:25 UTC
Regarding Noel's commit, I built LibreOffice at 2660d24a07866e083c5135ea263030f3e3a2e729 + 96ae2a3300811897c24cccb20f8c2faf382483df and the issue is fixed. So the dataloss while closing LibreOffice was introduced between both commits...
Comment 30 Xisco Faulí 2019-05-29 09:27:30 UTC
(In reply to Xisco Faulí from comment #29)
> Regarding Noel's commit, I built LibreOffice at
> 2660d24a07866e083c5135ea263030f3e3a2e729 +
> 96ae2a3300811897c24cccb20f8c2faf382483df and the issue is fixed. So the
> dataloss while closing LibreOffice was introduced between both commits...

After a long manual bisection building Libo on each step and applying 96ae2a3300811897c24cccb20f8c2faf382483df, I found when the problem got introduced:

author	Noel Grandin <noel.grandin@collabora.co.uk>	2017-06-29 08:15:20 +0200
committer	Noel Grandin <noel.grandin@collabora.co.uk>	2017-06-29 09:35:30 +0200
commit 497e40ad03c27837978551ba15491c3fb2a0bf53 (patch)
tree baa53156ae5234b65f645e11e590c64e569c6284
parent 71112060e0930fc58087c3762e836b1e12b60f75 (diff)
improve refcounting loplugin
Comment 31 Xisco Faulí 2019-05-29 09:50:14 UTC
Patch in gerrit: https://gerrit.libreoffice.org/#/c/73146/
it fixes both problems mentioned in comment 28, so the bisection from comment 27 is not relevant anymore...
Comment 32 Commit Notification 2019-05-29 11:06:08 UTC
Xisco Fauli committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/58f121ef2e680697e10453add43bab9b771d153a%5E%21

tdf#114596 dbaccess: fix mysterious dataloss bug (part 2)

It will be available in 6.3.0.

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

Affected users are encouraged to test the fix and report feedback.
Comment 33 Commit Notification 2019-05-29 14:17:14 UTC
Xisco Fauli committed a patch related to this issue.
It has been pushed to "libreoffice-6-2":

https://git.libreoffice.org/core/+/ebae54a6fde07a08e0b666b56dbd654691e5c416%5E%21

tdf#114596 dbaccess: fix mysterious dataloss bug (part 2)

It will be available in 6.2.5.

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

Affected users are encouraged to test the fix and report feedback.
Comment 34 Commit Notification 2019-05-31 10:22:56 UTC
Xisco Fauli committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/6f74de514e6a384b549ce2136037e03a60b1c54f%5E%21

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

It will be available in 6.3.0.

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

Affected users are encouraged to test the fix and report feedback.
Comment 35 Alex Thurgood 2019-11-11 11:08:40 UTC
@Xisco : sorry, should've read all the way to the end my bad, apols.