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.
standalone form got to be saved again
standalone form stays as it is
User Profile Reset: No
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 126.96.36.199 and newer versions like LO 188.8.131.52 or LO 184.108.40.206
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
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.
same behavior with:
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
MariaDB 10.3.25 database server
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 10 (buster)
Distributor ID: Debian
Description: Debian GNU/Linux 10 (buster)
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.
Thanks for testing this.
By any chance, is it possibly related to your bug 88551 ?
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.
(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)
> 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:
CPU-Threads: 4; BS: Linux 4.19; UI-Render: GL; VCL: gtk3_kde5;
Gebietsschema: de-DE (de_DE.UTF-8); Calc: group threaded
...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 220.127.116.11
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.
[Automated Action] NeedInfo-To-Unconfirmed