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.
I can confirm that behaviour, using LO 5.4.3 under Windows 7
Following comment1 I will set this bug to NEW.
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.
...it's the OBookmarkContainer change in dbaccess/source/core/dataaccess/datasource.hxx/.cxx...
hahaha... void SAL_CALL OBookmarkContainer::acquire( ) throw() { m_rParent.acquire(); }
fixed on master.
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.
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.
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.
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.
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
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.
