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.
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!
In master this problem is blocked by bug 125339
(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
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
(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
Ok, after different tries on mac, win and linux, I think I've found when the problem at closing time was introduced: Regression introduced by: author Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de> 2016-09-19 17:05:36 +0200 committer Thorsten Behrens <Thorsten.Behrens@CIB.de> 2016-10-10 10:36:02 +0000 commit 6d9f07d53e9f89b5286637113198e61149a5c771 (patch) tree 88399883432d86cbd1067b6ba83bd1989c0e8fcb parent 25767162edf38134c4412cce2a7d938f4657cc2d (diff) tdf#102288 TerminationVetoException should only prevent termination When using a TerminationVetoException, all windows should be closed, but the process should be kept running. Bisected with: bibisect-linux-64-5.3 Adding Cc: to Samuel Mehrbrodt Steps to reproduce: 1. Open attachment 138551 [details] 2. Enter the database to Tools > Options > Base > Databases (Name: TestDB) 3. Open the *.odt-file of the folder. 4. Click on later 5. Put data into tho only field for text and press Enter 6. Close LibreOffice, not the document and then LibreOffice 7. Open the database 8. Go to Tables 9. Click on Later -> The entry introduced is not saved
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
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...
(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
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...
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.
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.
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.
@Xisco : sorry, should've read all the way to the end my bad, apols.
