Description: Base when using the embedded firebird data engine does not write data to the disk until the user executes a file save. When a registered database using the firebird sdbc is opened in the beamer window (writer or calc) and data is entered into a table there is no way for the user to save the database (odb) file from that UI. The data entered will be lost when the file you are working on closes. Steps to Reproduce: 1. Download and open the attached firebird ODB file 2. open Tools|Options|Base|Databases 3. click on new and register the downloaded file. 4. Create a new Calc or Writer file 5. Open the beamer window (View|Data Sources) 6. double click on the newly registered database name from above 7. open the Tables entry and double click on the first table. (tbl_text_varchar) 8. A table grid displays to the right, in the beamer and shows it is ready to enter new records. 9. Enter a value in tst_data field for a new record. 10. Close the Calc or Writer file 11. Open the database file. 12. Open table tbl_text_varchar Actual Results: The record you entered, and thought you saved, in the beamer is gone. Expected Results: Record was retained in database table. Reproducible: Always User Profile Reset: No Additional Info: Tested on: Version: 6.1.0.0.alpha1+ Build ID: ecf50fe71596c3edba8ce437481ab80ae1cd8935 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-05-08_00:13:13 Locale: en-US (en_US.UTF-8); Calc: group User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/65.0.3325.181 Chrome/65.0.3325.181 Safari/537.36
Created attachment 141987 [details] test file (converted to firebird sdbc) Test firebird sdbc file
You are right. It is the same behavior when writing data in the table. The Save-button will be disabled after changing row - looks all pretty. Then you could close your document. When you use the databrowser in Writer or Calc there won't be any dialog for asking: Do you want to save your data. There is no possibility to save the data. Again: We should save data automatically: bug 117118. But this is set to enhancement ...
This scenario is indeed problematic. Tamas, any thoughts?
*** Bug 124843 has been marked as a duplicate of this bug. ***
(In reply to Drew Jensen from comment #4) > *** Bug 124843 has been marked as a duplicate of this bug. *** I think the solution is fairly straight forward. Move the event where the firebird database is written to disc from out of the file save function into the connection close function. How much that would take to move IDK but I'd bet dimes to euros that it would fix it and fix this new dup issue which is not about the beamer but about external forms (dataforms embedded in odt/ods/etc files), which act just as the beamer does. So; one thing. If you open the ODB before you close the file the external dataform is in (beamer or doc.drawpage.forms) the update data is visible in the ODB table, and if still open after you close the odt/ods the data is not lost. You just have to save the ODB file to make it stick.
Dear Drew Jensen, 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 https://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
Nothing has been changed her. Bug is almost the same in LO 7.1.2.2 on OpenSUSE 15.2 64bit rpm Linux.
Created attachment 173520 [details] Unzip the file, register database for Firebird as "Beispiel_Sport" and add data in form. Would be the same reason. Open the attached *.zip. Unpack it. Register database "Beispiel_Sport_Firebird.odb" as "Beispiel_Sport". Start the external form. Change data. When switching from on row to another data seem to be changed. Close the form and LO. Reopen LO and the form. Data won't be saved. You have to open the database before you close LO. Then you have to save the database. So external forms won't work with Firebird.
I've sent a patch https://gerrit.libreoffice.org/c/core/+/148368 I think solves this problem. Just in case somebody want to test it
My patch to tdf#117118 has been pushed to "master" (https://git.libreoffice.org/core/commit/9227fbabe0a33134f56aefdd8ec16024f006a659) and it solves also this bug, just case somebody want to test the fix and report feedback.
I've reverted the path, because generates a new bug, until further investigation
This is a bug with dataloss (high importance). Nothing new happens. I solved it by setting SUB DataSave(oEvent AS OBJECT) oEvent.Source.activeConnection.Parent.flush END SUB after any record action of external form. Isn't this also possible to write something like this directly in code of LO?
I added a new patch which solves the previous patch malfunction, but it is waiting for revision or comment for more than two months...
Solved with fix for Bug 117118. Could input data. Could go to next row. Could change data. Could close the form (irritating Writer-warning Document has been changed…). When opening the database all data will be saved.