Description: When using a standalone form for Base, any add, change or delete seems to work. Changes made are visible when records scrolled through. When the form is closed & re-opened, the changes are gone. Steps to Reproduce: 1.Open standalone form 2.Add, change or delete record(s) 3.close then re-open form Actual Results: Changes gone. Expected Results: Retain changes. Reproducible: Always User Profile Reset: No Additional Info: If the standalone form is opened and changes made, and before closing the form the .odb is opened & table data is viewed (nothing more) and then all closed, the modifications are retained. Without doing this all changes are lost. This did work on v5.2.5.1 Tested with daily and did not work: Version: 5.4.2.0.0+ Build ID: 61d85c4e7c30ea0f5242d927b7456190020b4fbe CPU threads: 4; OS: Linux 4.8; UI render: default; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:libreoffice-5-4, Time: 2017-09-15_12:00:43 Locale: en-US (en_US.UTF-8); Calc: group Samples attached: Customers.odb (need to register); CustomersEntry.odt (set for Customers registered name) User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.91 Safari/537.36
Created attachment 136320 [details] Database table for test
Created attachment 136321 [details] Standalone Form for Test
No repro Version: 5.4.1.2 Build ID: ea7cb86e6eeb2bf3a5af73a8f7777ac570321527 CPU threads: 4; OS: Mac OS X 10.12.6; UI render: default; Locale: fr-FR (fr_FR.UTF-8); Calc: group I didn't even need to register the database. Open the standalone form. Activate Form Design mode. Right mouse button click to bring up Form properties, choose Data tab. Indicate datasource (path to ODB), and table (Customers), close the properties dialog, then save the ODT file. Leave Form design mode to switch back to data entry mode. Add a new record via the form. Use the back arrow to move back to a previous record, thereby validating new record data entry. Save the form before closing. Open the ODB file. See that the newly entered data appears in the table.
System using Mint18.2: Version: 5.4.1.2 Build ID: ea7cb86e6eeb2bf3a5af73a8f7777ac570321527 CPU threads: 4; OS: Linux 4.8; UI render: default; VCL: gtk2; Locale: en-US (en_US.UTF-8); Calc: group regardless of using registered name or path to .odb the record is NOT saved. Checking multiple LO versions back this is true until I get to v5.2.5.1 and then it is working. Just reran using your step-by-step process.
Could reproduce the buggy behavior with LO 5.4.1.2 on OpenSUSE 42.2 64bit rpm Linux. Have registered the database as "Customer". Could input a new row. Moved to next row. This should work. Also pressed the button "Save" of the navigationbar. Closed the database and switched to LO-Desktop. Reopened the database: Data could be read, but ... When I close the whole LO and the reopen the new data have been gone. The standalone-form doesn't work right. Don't know why the Save-button of the writer-document will save something, but this won't have any effect. Note: When only opening the database Customers.odb before closing the whole LO the data will appear and will be saved.
Have tested a little bit more: Last installed version where the whole content of the form will be saved without opening database afterwords is LO 5.0.5.2. Could reproduce the buggy behavior with LO 5.1.0.3 and all newer versions, also 5.1.5.*, 5.2.0.*, 5.2.5.* ... I will set this bug to the oldest version where the bug appears. I would also prefer to set the Importance to high and major, because of dataloss, but I have no permission to do this.
On pc Debian x86-64 with master sources updated yesterday, I noticed this on console during my tests: warn:legacy.osl:5792:5792:dbaccess/source/core/dataaccess/ModelImpl.cxx:903: DBG_UNHANDLED_EXCEPTION in static bool dbaccess::ODatabaseModelImpl::commitStorageIfWriteable_ignoreErrors(const com::sun::star::uno::Reference<com::sun::star::embed::XStorage>&) type: 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: N4cppu16ComponentContextE but it's not clear to me when the save must be done. I can't help here.
I have come up with a work around. If the database is split then the standalone works. The problem only seems to occur when using embedded DB.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Bug still exists in LO 6.1.3.2., OpenSUSE 15, 64bit rpm Linux. Standalone forms are unusable with this bug! You could work around this with --------- Sub S_FLUSH(EVENT) EVENT.SOURCE.ACTIVECONNECTION.flush End Sub --------- Start this "After record action" and the data will be saved.
Created attachment 147213 [details] bibisect in till51 repo, tail of terminal output Working on debian-buster in the daily till51 bibisect repository, I see that the bug came into LibreOffice sometime in the 53 or so commits: commit date s-h -------- ---------- -------- good 567a8477 2015-08-03 71ace488 bad b6f9394f 2015-08-04 cd6c9aef which is to say <https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=71ace488..cd6c9aef> I am removing key bibisectRequest and adding bibisected.
(In reply to Terrence Enger from comment #11) > (...) I see that the bug came into LibreOffice sometime in > the 53 or so commits: > <https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=71ace488.. > cd6c9aef> From looking at these commits, a prime suspect is: https://cgit.freedesktop.org/libreoffice/core/commit/?id=2660d24a07866e083c5135ea263030f3e3a2e729 since it touches lifecycle management... Maybe the data source is not any more destroyed, or destroyed at a different time? The debug message in comment 7 looks relevant. Other commits that touch database stuff is https://cgit.freedesktop.org/libreoffice/core/commit/?id=7339c360ef55fdde99907e1e34a231386ebc534e and its followup https://cgit.freedesktop.org/libreoffice/core/commit/?id=37ec6cbeebc5dc9bf642eedcf45f0441edd3d610 But, true, the bug may come from outside database code altogether, so theoretically possible a sw or sc change is responsible.
(In reply to robert from comment #10) > You could work around this with > --------- > Sub S_FLUSH(EVENT) > EVENT.SOURCE.ACTIVECONNECTION.flush > End Sub > --------- > Start this "After record action" and the data will be saved. This looks like either the standalone form doesn't flush the connection when it is being closed, _or_ it tries, but that fails (because the connection is already destroyed?), _or_ the connection doesn't correctly flush itself when it is being closed (comment 7 could be relevant there), _or_ the connection is never closed / closed at the wrong moment (which brings us back to lifecycle management).
(In reply to Stang from comment #8) > I have come up with a work around. If the database is split then the > standalone works. The problem only seems to occur when using embedded DB. Hmm... Does it work with an embedded Firebird database, or is the bug also present there?
(In reply to Lionel Elie Mamane from comment #14) > (In reply to Stang from comment #8) > > I have come up with a work around. If the database is split then the > > standalone works. The problem only seems to occur when using embedded DB. > > Hmm... Does it work with an embedded Firebird database, or is the bug also > present there? No, doesn't work with embedded Firebird. Have just migrated a database for a standalone form. Data weren't saved after closing the form and LO.
(In reply to Lionel Elie Mamane from comment #13) > This looks like either the standalone form doesn't flush the connection when > it is being closed, _or_ it tries, but that fails (because the connection is > already destroyed?), _or_ the connection doesn't correctly flush itself when > it is being closed (comment 7 could be relevant there), _or_ the connection > is never closed / closed at the wrong moment (which brings us back to > lifecycle management). Funnily enough, the change _persists_ if you close LibreOffice from the form. The change is _lost_ if you close the form window and then close LibreOffice from Start Center.
(In reply to Terrence Enger from comment #16) > > Funnily enough, the change _persists_ if you close LibreOffice from > the form. The change is _lost_ if you close the form window and then > close LibreOffice from Start Center. Couldn't confirm that there is any difference. If you haven't opened the database-file itself, the behaviour is always the same: Data were lost. - Direct closing LO directly. - Closing the external form, then LO. When closing the external form, reopen the form there is a difference between HSQLDB and Firebird: HSQLDB shows the new entries, but looses these entries if you close sometimes LO. Firebird doesn't show any new entry. Seems database has been shut down complete for Firebird when closing the form, but will be shut down for HSQLDB when closing LO.
Created attachment 147232 [details] bibisect in till53 repo, tail of terminal output I now think I see that behaviour deteriorated in two steps: (1) To close LibreOffice directly from the form loses changes, but changes persist after closing the form window and then closing LibreOffice from Start Center. Comment 11 reports my results bibisecting this problem. (2) Additionally, to close the form window and then closing LibreOffice from Start Center loses change. This is what robert reports in comment 17. Working on debian-buster in the till53 bibisect repository, I see that bug (2) entered LibreOffice in the 57 or so source commits <https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=8bfbd7fb..e2f6c7f0>. To summarize: changes ... commit date s-h ---------------------------- -------- ---------- -------- persist 567a8477 2015-08-03 71ace488 persist if close LO directly b6f9394f 2015-08-04 cd6c9aef persist if close LO directly 8bb36bab 2016-10-10 8bfbd7fb lost either way 49fe466f 2016-10-11 e2f6c7f0
With version 6.1.2.1 on MacOS Mojave (10.14) this bug now also shows using standalone ODT form and an ODB database. In all previous version it was not there and the combination worked well. Unfortunately I cannot tell whether the OSX update or the LibreOfice update caused the change in behavior.
When I try to test this in a current master build, all of the "new record", "save record", etc, buttons on the document are disabled? what am I doing wrong?
I'm guessing I'm missing a step like 'register the database'? clearly just putting the form document and the ODB file in the same folder, and then opening the form document does not work :-(
(In reply to Noel Grandin from comment #21) > I'm guessing I'm missing a step like 'register the database'? clearly just > putting the form document and the ODB file in the same folder, and then > opening the form document does not work :-( If you are trying to reproduce the bug with the example database, you have to register the database as "Customer". (See comment 5)
The same bug appars on 6.2.0.3
(In reply to Terrence Enger from comment #18) > > Working on debian-buster in the till53 bibisect repository, I see that > bug (2) entered LibreOffice in the 57 or so source commits > <https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=8bfbd7fb.. > e2f6c7f0>. > Of those, I see : https://cgit.freedesktop.org/libreoffice/core/commit/?id=ecec5524476448d35dd24c5594c2fcbb1a8b6218 and possibly : https://cgit.freedesktop.org/libreoffice/core/commit/?id=6d9f07d53e9f89b5286637113198e61149a5c771 as being potential candidates, although the first would be my prime suspect...as it appears to allow closure of frames if it can't find a parent UNO context, and I seem to recall that standalone forms don't have that parent frame context unless the ODB file is also loaded in memory...
Created attachment 155716 [details] Firebird flush error Firebird flush error
Because of tdf#128607 I came back to test this once again Linux Ubuntu 18.04 Mate. With TDF v6.3.3.2 and using HSQLDB (attachment versions) the problem is no longer present and the 'flush' command was not needed. Did go back to previous versions. This seems to have begun working in v6.2.5.2 but did not work in v6.2.4.2 If using Firebird embedded this still does not work in v6.3.3.2 which errors out when using the flush command. Will attach image.
Have now been able to get Firebird embedded to work by modifying the fix in comment#10 to: EVENT.SOURCE.ACTIVECONNECTION.Parent.flush
I created an odb (Firebird option) in LibreOffice 6.3, following info from the Frugal guy, and there as far as I remember the standalone forms did their job well (adding, changing records). Since then, I had to pause this work and recently I restarted it, while in the mean time LibreOffice got updated to 6.4.x I've tested with LO 6.4.6.2 on Mageia linux 7 and 6.4.4 or 6.4.7 on Windows 10, and this bug is there (again?). I closed the form window as suggested in Comment #18, but to no avail. I wil try the workaround from Comment #27, report on it later
I tested the workaround on one of the standalone forms and it seems OK, but it remains a PITA
Using LO 6.4.7.2, the problem seems to have been cured for a simple form based on one table. But not for a subform. There I still need the workaround.
Tested this again with a external form. Data would be saved in form and in subform without problem. Bug has been gone since LO 6.3.5 here. Tested with different versions: 6.1.5.2: Open the form, input data, close the form and LO → reopen LO and no data are there. Then since LO 6.3.5, also with LO 7.1.5.1: data will be there after restarting LO and opening the form → also in a subform. All tested on OpenSUSE 15.2 64bit rpm Linux. I will close this bug as WORKSFORME. Feel free to reopen if you could reproduce the bug with LO 7.1 and newer.
Still a problem: Version: 7.1.4.2 / LibreOffice Community Build ID: a529a4fab45b75fefc5b6226684193eb000654f6 CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Current test with Firebird embedded. Works only if DB is open. Otherwise workaround is still needed. Ubuntu 20.04
(In reply to Stang from comment #32) > Still a problem: > > Version: 7.1.4.2 / LibreOffice Community > Build ID: a529a4fab45b75fefc5b6226684193eb000654f6 > CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3 > Locale: en-US (en_US.UTF-8); UI: en-US > Calc: threaded > > Current test with Firebird embedded. > > Works only if DB is open. Otherwise workaround is still needed. > > Ubuntu 20.04 Let us open a new bug for this. The bug was described with a HSQLDB-database. With HSQLDB it will work now. Seem it is a special Firebirdbug. I Open a new bug for this and add an example-database. Please confirm this new bug.
(In reply to Stang from comment #32) > Still a problem: > > Version: 7.1.4.2 / LibreOffice Community > Build ID: a529a4fab45b75fefc5b6226684193eb000654f6 > CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3 > Locale: en-US (en_US.UTF-8); UI: en-US > Calc: threaded > > Current test with Firebird embedded. > > Works only if DB is open. Otherwise workaround is still needed. > > Ubuntu 20.04 What you report special for Firebird is already reported: bug 117513
I would prefer to close this bug. Firebird has a special problem to save data without pressing "Save" in the database file. This is reported in bug 117513. So you have to open the database also if you are working with database browser in Writer or Calc.
HSQLDB embedded works.