Description: Every query in standalone forms are changing the status of the document → it have to be saved again; this means the document (form.ods) has to be saved, not the data. This doesn't happen when using the form inside base. Steps to Reproduce: 1.take a standalone form within a query or filter 2.change some data or go to another filter entry, so that the data of the site is changing 3.the file of the standalone got to be saved again without necessity. Actual Results: standalone form got to be saved again Expected Results: standalone form stays as it is Reproducible: Always User Profile Reset: No Additional Info: System: Debian 10
Have created an external form for a database. Table as datasource for this form. Changed some content. No saving of the *.odt-file is necessary. So I couldn't confirm the buggy behavior with OpenSUSE 15.1 64bit rpm Linux. Tested with LO 6.2.6.2 and newer versions like LO 6.4.6.2 or LO 7.0.3.1 Older versions of LO aren't running here with Base. I haven't installed such an old version of Java, that will work with that old versions.
This was behaviour inherited from OOo. I used to see it with standalone forms stored on a file server, and using a mysql backend for the database source. As the version of LibreOffice that you mention is causing the problem is end of life, it won't be fixed for any of the 6.1.x line. As Robert has said, try with an uptodate release of LibreOffice. If the problem is still there, report back on your findings, and please indicate which OS and version you are using, and which kind of backend database you are using.
Created attachment 166739 [details] Example - Filter Hello, here is an example database which shows the same effects. Build an standalone form, just select a new row of data → the form got to be saved instead it hasn't changed. Greetings Michael
Hello, same behavior with: Version: 7.0.2.2 Build ID: 8349ace3c3162073abd90d81fd06dcfb6b36b994 CPU threads: 4; OS: Linux 4.19; UI render: GL; VCL: kf5 Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded Server: MariaDB 10.3.25 database server Distributor ID: Raspbian Description: Raspbian GNU/Linux 10 (buster) Release: 10 Codename: buster Client: Distributor ID: Debian Description: Debian GNU/Linux 10 (buster) Release: 10 Codename: buster Greetings Michael
There seems to be something buggy with the table control in the special form. I have saved a copy of one form you created. The status of the document changes every time I scroll though the table control. Then I changed the whole form and only connected the table control to the table "Table" of the example database. Scrolling through the form changes the status. Then I deleted the table control and created it new. Scrolling through the form doesn't change the status. So I deleted the table control in the first export. Also the status doesn't change any more. I will try a little bit more to find the reason.
I tested it a little bit more. Deleted the table control in the form of the Base file. Created it new by the table control wizard. Exported this form and connected it to the database. The status of the document doesn't change any more. Don't know what is defect with the table control in the forms of your example. But the bug couldn't be reproduced with a new created table control.
Hi Robert, Thanks for testing this. By any chance, is it possibly related to your bug 88551 ?
Hello, I did as you suggested. It's right, after recreating the table the problem of saving every time the data is changing disappears. But I guess there is something hidden behind this behavior. Greetings Michael
(In reply to Alex Thurgood from comment #7) > Hi Robert, > Thanks for testing this. > > By any chance, is it possibly related to your bug 88551 ? Couldn't be, because I have tested all without activated macro support. By the way: This event in macros will only happen for content of the database, not for content of the form document.
(In reply to michael from comment #8) > Hello, > > I did as you suggested. It's right, after recreating the table the problem > of saving every time the data is changing disappears. > > But I guess there is something hidden behind this behavior. > With which version of LO did you create this Base forms? Could be this is an old bug, which has been gone with new created forms. As Alex wrote in https://bugs.documentfoundation.org/show_bug.cgi?id=137732#c2 this could have been a bug inherited from OOo.
The forms were created with: Version: 6.1.5.2 Build-ID: 1:6.1.5-3+deb10u6 CPU-Threads: 4; BS: Linux 4.19; UI-Render: GL; VCL: gtk3_kde5; Gebietsschema: de-DE (de_DE.UTF-8); Calc: group threaded Thanks Michael
...but as I mentioned before, it happens also when I create the standalone form with version 7.0
@Michael : if you use a different VCL backend, e.g. gen, or gtk3 (without reference to kde), do you still see the same problem ? I'm wondering if this is specific to the gtk3_kde5 VCL engine.
The example database was not created by me and I don't know under which version it was created. It happens with gtk3, gtk3-kde5 and kf5 - ((I guess there is no support on debian so far for all qt-libraries?)) The only way to get rid of the re-saving everytime is to delete the table and recreate it - this is true for both versions - 6.1.4 and 7.0.0.2 I saw that it happens also with buttons (forward, backwards a.s.o.) - I didn't tested to rebuild the buttons or test if it is still the case when the table is recreated. Thanks Michael
[Automated Action] NeedInfo-To-Unconfirmed
Hello michael, Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Dear michael, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear michael, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp