Download it now!
Bug 137732 - Every query in standalone forms are changing the status of the document
Summary: Every query in standalone forms are changing the status of the document
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
6.1.5.2 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-10-25 11:57 UTC by michael
Modified: 2020-10-27 04:26 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Example - Filter (69.41 KB, application/octet-stream)
2020-10-26 14:40 UTC, michael
Details

Note You need to log in before you can comment on or make changes to this bug.
Description michael 2020-10-25 11:57:05 UTC
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
Comment 1 Robert Großkopf 2020-10-25 15:14:38 UTC
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.
Comment 2 Alex Thurgood 2020-10-26 08:23:27 UTC
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.
Comment 3 michael 2020-10-26 14:40:59 UTC
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
Comment 4 michael 2020-10-26 14:52:05 UTC
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
Comment 5 Robert Großkopf 2020-10-26 16:09:49 UTC
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.
Comment 6 Robert Großkopf 2020-10-26 16:24:08 UTC
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.
Comment 7 Alex Thurgood 2020-10-26 16:37:49 UTC
Hi Robert,
Thanks for testing this.

By any chance, is it possibly related to your bug 88551 ?
Comment 8 michael 2020-10-26 16:44:47 UTC
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
Comment 9 Robert Großkopf 2020-10-26 16:47:38 UTC
(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.
Comment 10 Robert Großkopf 2020-10-26 16:51:09 UTC
(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.
Comment 11 michael 2020-10-26 17:11:57 UTC
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
Comment 12 michael 2020-10-26 17:13:48 UTC
...but as I mentioned before, it happens also when I create the standalone form with version 7.0
Comment 13 Alex Thurgood 2020-10-26 17:35:09 UTC
@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.
Comment 14 michael 2020-10-26 18:21:35 UTC
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
Comment 15 QA Administrators 2020-10-27 04:26:33 UTC Comment hidden (obsolete)