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.
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.
(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 ...
oh, so you migrated the ddbb? Could you please try without migrating the ddbb ?
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.
don't have time to investigate this further now...
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.
"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.
(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.
This is absolutely a data validation issue. For us it was the date fields - once buttoned up, issue resolved.