Base Sub Form edit update does not flush to database

[ramontochip]

We have Form A and Form B
Form A contains data from Table “order_to_supplier” alias ots.
Form B is subform for Table item_inventory alias “ii”

Table ii has primary key on column “itemid”.
Table ots has primary key on column “itemid” and “supplierid”
Table ots has referential key on column itemid from Table ii

Whenever we edit data in Form B (table ii) and if we explicit press “save record” button, it will be “flushed to database”. But if we edit in Form B and go to Form A by clicking on a field in form A on the SAME row (without pressing save record), the data will not be “flushed” to the database. We then click on the previous or next record in Form A. When we go back to the “edited” record in Form A, the changes is not flushed to database. The changes will “disappear”.

This problem occured Libreoffice 7.3.7.2 after upgrade Ubuntu 22.04.

Before the upgrade, the problem was not present in ubuntu 20.04. The libreoffice version was 5.something which i cannot remember.

Is this a bug? or a purposedly designed?

[ramontochip]

Additional info:
the NO-SAVING problem happens when we use the mouse to click to go to next record.

if we use the navigator arrow to go up and down record, this problem does not exist and the edited data are saved.

[Villeroy]

Whcih database? Embedded Firebird?

[RobertG]

Which version of LO do you use? Copy Help → About LibreOffice → Version Information.

Might be it is a specific buggy behavior of gtk3 or special Ubuntu version.

Would be good to get a database with this buggy behavior for testing - without personal data, only tables and forms.

[ramontochip]

database = psql (PostgreSQL) 14.8 (Ubuntu 14.8-0ubuntu0.22.04.1)
pg_lsclusters = Ver 12

please note that we have NOT YET upgraded the database from version 12 (ubuntu 20.04) after updating ubuntu to 22.04

[ramontochip]

The libreoffice version is shown above in the 3rd last paragraph (Libreoffice 7.3.7.2 after upgrade Ubuntu 22.04),

Yes, I think the buggy behavior probably in the user interface as this happens during “mouse clicking” to move the active field/form but does not happen when the “navigator arrow” is used.

[RobertG]

@ramontochip

The libreoffice version is shown above in the 3rd last paragraph (Libreoffice 7.3.7.2 after upgrade Ubuntu 22.04)

You could install different versions from LO. This is the reason I asked for “Version Information”. Did you install the version, which has been provided directly from Ubuntu or is it the version downloaded from LibreOffice? Do you use gtk3 or do you use kde?

For testing: Start LO with SAL_USE_VCLPLUGIN=gen soffice (could be it isn’t soffice for you, might be something else …)

[ramontochip]

a) We let ubuntu 22.04 upgrade and install the libreoffice version. We didn’t choose to download a specific version of lo.

b) running “gtk-launch --version” gives “3.24.33”. I think i am using gtk3 rather than kde.

c) By running “SAL_USE_VCLPLUGIN=gen soffice”, we get the old windows appearance. It seems to be faster (see d) below) then we can’t seem to replicate the error. It does seem to work properly.

d) one thing we noticed after upgrade was that the user interface for the LO base FORMS was slower. But after running under c) above, it seems to be faster. It is at the same speed(or maybe faster response) as before upgrading to version 7.3.7.2.

e) there must be something wrong with my graphical user interface?

[RobertG]

So it seems to be a special problem of gtk3. But we don’t know if this is a special problem of the Ubuntu-version of LO.

It would be good to get an example with an internal database, which throws this error on your system. So other people (with gtk3 and LO installed directly from LibreOffice) could test. The first comment to a bug will be: Could it be reproduced with a version directly installed from packages from LO. And if this could be reproduced the bug will be set to NEW and developer, special for gtk3, will have a look.

[Villeroy]

Try turning off gtk:
Shut down LibreOffice and start it from terminal like this: SAL_USE_VCLPLUGIN=gen libreoffice

I have seen it several times on Windows and Linux too that the visual representation of a form control within a table control is not properly updated. In particular, it shows the value of an edit that has been canceled. Replace “foo” with “bar” and hit the cancel button before saving. The record marker indicates a clean, unmodified value “bar” although the actual value is “foo”. Reloading the form helps in this case.
Please investigate if the form represents what is actually stored in the underlying database table. You may use another database frontend or simply open the raw table view and refresh it.

[ramontochip]

I think it is not only the visual representation that is not properly updated because i just opened a query directly to the table to check a few hours ago without using the LO form and the data is NOT properly “flushed” or saved to the database. I will try again tomorrow (it is now 8:49pm here) and test again by comparing the data with a psql client to query the table in the postgresql server.

UPDATE 1: yes, i can confirm that the edits are not updated to the postgresql database. I sent a query through psql client and it does not show the edited data. BUT…

UPDATE 2: it seems to be a race condition as there instances NOW where the data are reflected in the form as well as in the database.

[ramontochip]

Hello and here is a delayed update to the problem. We have screenshot of our database forms.
A is the “search form”.
B is the subform of A.
C is the subform of B
D is the subform C.
E is the “save record” button.

When we edit data in form C, the “E” button to save record is sometimes not activated. This probably means the UI (gtk?) does not recognize changes to the form field or column. When we change record to the next or previous in form B, changes in form C is lost. However though sometimes it is activated to allow explicit save record. NOT using gtk3 does not have this problem and is SO MUCH faster response from the user interface. gtk3 is very slow. There is a half-second delay between clicking on the field or column and allowing edits.

[RobertG]

Only thing I would test now: Install LO from LibreOffice directly. Download the packages of www.libreoffice.org. If you could reproduce the behavior with GTK3 and this version write a bug to https://bugs.documentfoundation.org/

[ramontochip]

Got it RobertG. But we will do it over the weekend so we have time to recover in case any problem comes up as this database is used for business.

We will report back next weekend.

Thanks.