Bug 91600 - EDITING: oForm.UpdateRow() doesn't refresh all fields of a form
Summary: EDITING: oForm.UpdateRow() doesn't refresh all fields of a form
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: x86-64 (AMD64) All
: medium major
Assignee: Not Assigned
Depends on:
Reported: 2015-05-25 07:35 UTC by Robert Großkopf
Modified: 2022-06-09 07:34 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

Activate macros. open the database, open the form and press the button ... (13.67 KB, application/vnd.oasis.opendocument.database)
2015-05-25 07:35 UTC, Robert Großkopf

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Großkopf 2015-05-25 07:35:29 UTC
Created attachment 116005 [details]
Activate macros. open the database, open the form and press the button ...

1. Activate LO to execute macros.
2. Open the attached database.
3. Open the form.
4. Press the button «Set all fields except primary key "ID" NULL».
The value in the field "firstname" disappears. All other values seem still be saved in the table.
5. Go to next row.
6. Go back to first row.
All fields except "ID" are empty.

The macro:
SUB SetNull(oEvent AS OBJECT)
	oForm = oEvent.Source.Model.Parent
All fields are set NULL except "ID". This works right. UpdateRow works right except refreshing the content of all fields to the new content.

Expected behavior: UpdateRow should refresh content of all fields of a row to see the saved values in the table of the database.

I set the severity of this bug to «major». For normal users there seem to be data loss while switching from one row to another.

Bug appears on OpenSUSE 13.2 64bit rpm Linux with every installed LO-Version including LO 3.*. So I set the version to «Inherited from OOo»
Comment 1 Alex Thurgood 2015-05-29 14:34:10 UTC
Confirming on

Build ID: 8cbb94a2b79dcaf9675125da800b64a85bae52dc
Locale : fr-FR (fr.UTF-8)

OSX 10.10.3

It is even worse if you proceed from one record to next, clicking on button as you go. By the time you reached record 3, and clicked button, then step back one record, you see the remnants of record 3 in record 2 and even in record 1, where the screen doesn't get updated.
Comment 2 Alex Thurgood 2015-05-29 14:36:36 UTC
Physically calling Form reload via the context menu in the form doesn't change the result of corrupted screen data display.
Comment 3 QA Administrators 2017-09-01 11:21:02 UTC Comment hidden (obsolete)
Comment 4 Alex Thurgood 2017-09-05 10:01:13 UTC
Still present in 

Build ID: 595371e520ce4f64ad9d99a7866bdb8404271b6e
CPU threads: 4; OS: Mac OS X 10.12.6; UI render: default; 
Locale: fr-FR (fr_FR.UTF-8); Calc: group
Comment 5 QA Administrators 2018-09-06 02:59:21 UTC Comment hidden (obsolete)
Comment 6 Robert Großkopf 2018-09-06 14:10:32 UTC
Bug still exists in LO, OpenSUSE 15, 64bit rpm Linux
Comment 7 Julien Nabet 2018-09-09 19:10:23 UTC
On pc Debian x86-64 with master sources updated 2 days ago, I've got a different behaviour.
When I click "Set all fields except primary key "ID" NULL", only firstname is cleared.
But if I go to next record then go back to previous record, all the fields (except ID) are indeed clear.
Comment 8 Julien Nabet 2018-09-09 19:55:15 UTC
First line of the below bt shows where the updated is done with a preparedStatement containing "?" but cache mechanism isn't clear for me.

#0  0x00007fffdb04d817 in dbaccess::OKeySet::updateRow(rtl::Reference<connectivity::ORowVector<connectivity::ORowSetValue> > const&, rtl::Reference<connectivity::ORowVector<connectivity::ORowSetValue> > const&, com::sun::star::uno::Reference<com::sun::star::sdbcx::XColumnsSupplier> const&) (this=0x55555c69aa40, _rInsertRow=rtl::Reference to 0x55555c8666e0, _rOriginalRow=rtl::Reference to 0x55555c69cb50, _xTable=uno::Reference to (dbaccess::ODBTableDecorator *) 0x55555c07cc40)
    at /home/julien/lo/libreoffice/dbaccess/source/core/api/KeySet.cxx:445
#1  0x00007fffdb0eab26 in dbaccess::ORowSetCache::updateRow(__gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator<rtl::Reference<connectivity::ORowVector<connectivity::ORowSetValue> >*, std::__cxx1998::vector<rtl::Reference<connectivity::ORowVector<connectivity::ORowSetValue> >, std::allocator<rtl::Reference<connectivity::ORowVector<connectivity::ORowSetValue> > > > >, std::__debug::vector<rtl::Reference<connectivity::ORowVector<connectivity::ORowSetValue> >, std::allocator<rtl::Reference<connectivity::ORowVector<connectivity::ORowSetValue> > > > > const&, std::__debug::vector<com::sun::star::uno::Any, std::allocator<com::sun::star::uno::Any> >&) (this=0x55555c699fa0, _rUpdateRow=rtl::Reference to 0x55555c8666e0, o_aBookmarks=std::__debug::vector of length 0, capacity 0) at /home/julien/lo/libreoffice/dbaccess/source/core/api/RowSetCache.cxx:1338
#2  0x00007fffdb0acf9a in dbaccess::ORowSet::updateRow() (this=0x55555b6922e0) at /home/julien/lo/libreoffice/dbaccess/source/core/api/RowSet.cxx:954
#3  0x00007fffacf37b85 in frm::ODatabaseForm::updateRow() (this=0x55555b691b70) at /home/julien/lo/libreoffice/forms/source/component/DatabaseForm.cxx:3434
Comment 9 QA Administrators 2019-09-10 08:45:30 UTC Comment hidden (obsolete)
Comment 10 Robert Großkopf 2019-09-10 14:55:26 UTC
Bug still exists in LO, OpenSUSE 15 64bit rpm Linux.
Comment 11 QA Administrators 2021-09-10 04:14:19 UTC Comment hidden (obsolete)
Comment 12 Robert Großkopf 2021-09-10 05:38:56 UTC
Bug is still the same with LO on OpenSUSE 15.2 64bit rpm Linux.
Comment 13 evgeniya.panfilova91 2022-06-09 07:34:07 UTC Comment hidden (spam)