Apache OpenOffice (AOO) Bugzilla – Issue 127591
Record multiplication scrolling a large Base table
Last modified: 2017-11-19 14:58:48 UTC
Created attachment 86255 [details] Screenshot of unique ID multiplicated A record multiplicates itself scrolling up a Base table of at least one hundred rows, if not all the records are loaded. Steps to reproduce: 1) In Base create a new database. 2) Create a table, also with a single column of unique ID. 3) Populate the table with at least one hundred rows. 4) Open the table. The navigation bar displays that not all the records are loaded, but only about 50: you will read something like "Record 1 of 52*" with an asterisk (*). Scroll down the vertical bar until the loaded records reach next step (about 80), but stop before loading all the records. Then scroll up. Soon in the table you will see one record multiplicated and replacing many other rows. The same problem occurs in a Table control of a Base Form. And viewing this table in Data Sources of Writer and Calc. This bug was already reported in 2012 on Issue 22831 (from comment number 5), but I think this is an independent issue, since it was only a sub-argument there. I'm using OpenOffice 4.1.4 on Windows 10. In LibreOffice 5 there is no this bug.
Created attachment 86260 [details] Animated GIF to illustrate I was not able to reproduce with AOO 4.1.4 and Windows 7 x64 Pro. Tested with a table with 1003 records When I click on "last record" button, I jump on on record # 1003
(In reply to oooforum (fr) from comment #1) > When I click on "last record" button, I jump on on record # 1003 Jumping to the last record you will not see the bug, because you load all the records. OpenOffice is designed to load only an amount of records when you open a table, 40/80 records it depends. You see the number of loaded records with an asterisk * that means there are still records to load. When you instantly reach last record the asterisk disappears and by this way the bug will not show. The bug happens only if one part of the records is loaded, and then you scroll up. To see the bug you have to scroll down with vertical bar, mouse wheel, or with "next record" button ▶, loading only an amount of records but not all (the number of loaded records increases say from 50* to 80*, but asterisk still remains). After that you have to scroll up the table, again whit vertical bar, mouse wheel, or "prev record" button ◀.
This is a duplicate of 22831
Marked as duplicate of#22831 *** This issue has been marked as a duplicate of issue 22831 ***
(In reply to Keith N. McKenna from comment #4) > Marked as duplicate of#22831 > > *** This issue has been marked as a duplicate of issue 22831 *** that is duplicate of #22831
(In reply to mgroenescheij from comment #3) (In reply to Keith N. McKenna from comment #4) > > *** This issue has been marked as a duplicate of issue 22831 *** Sorry guys, I have a doubt: maybe this should be an independent issue and not a duplicate one? This issue was opened because issue #22831 doesn't really deal with the bug of record multiplication (aka the 'repaint' bug). The main argument of #22831 is about the difficulty to scroll down a table: > vertical scroll-bar doesn't reflect the true size of the table. > Scrolling stops at record 40. Although now is shown "Record 40 of 67" or similar > you can not continue scrolling... Only nine years after first post in #22831 was introduced the subject of record multiplication (from comment number 5): > when scrolling backup randomly a record will start to multiply itself over and over again. These are two distinct problems in the same issue, as mgroenescheij confirms in his comment https://bz.apache.org/ooo/show_bug.cgi?id=22831#c20 > The first Comment is annoying while the second problem is a real bug. > ... we mix two complete different bugs or request for changes. To avoid the confusion between two distinct problems (scroll down and record multiplication), I thought it was better to create this independent issue for the bug of record multiplication. The "bug writing guidelines" suggest that a useful bug report is *specific*: > The quicker the engineer can isolate the issue to a specific problem, > the more likely it'll be expediently fixed. So I ask you to consider reopening this specific issue. 😊
I can sometimes reproduce this bug, and believe it's not a duplicate.
It's probably some form of corruption in the data structure used to hold the table, as copying the data to Calc when it looks duplicated, results in duplication there too.