Apache OpenOffice (AOO) Bugzilla – Issue 128108
Phantom records in table display view
Last modified: 2020-01-21 04:35:51 UTC
Created attachment 86678 [details] Open table "Accounting" to see issue. Please see https://forum.openoffice.org/en/forum/viewtopic.php?f=61&t=97969 for description of problem in detail, verification by another user, and workaround. When a table is opened for display, phantom lines may appear at the end of the table that are duplicates of lines earlier in the table. The phantom lines cannot be selected, and aren't actually in the table (confirmed by SQL query). Similar phantom lines may appear in grid controls on forms. The problem appears to be sensitive to the number of lines in the underlying table as well as to the size of the display window. To the best of my knowledge this is a harmless problem, but annoying. Because I thought the data table might have been corrupted, I spend a lot of time writing macros to inspect the data and recreate the table, learning in the process that the same issue occurred on any table whether I copied it using the GUI or generated and filled it using SQL. I'm attaching a database that illustrates the problem. When the table "Accounting" opens, the record counter says there are 58 records, but the actual table only has 40. The extra 18 are duplicated at the end of the display.
Unable to open table: the connection to the datasource "OneTableTest" could not be established
Don't understand that. I just tested the table in the attachment (correct name is "Accounting-new" by the way). The database opens and shows the table as described in the bug report. This is using Open Office 4.1.6 on Windows 7. I opened the file I had uploaded with the bug report.
This is strange. When I open the table I see dublicates from 1-36. The shadow rows that you describe. But as soon as I press sort, there are only 40 left. Does this happen on your side too?
(In reply to Peter from comment #3) > This is strange. > > When I open the table I see dublicates from 1-36. The shadow rows that you > describe. > But as soon as I press sort, there are only 40 left. > Does this happen on your side too? Never tried it previously, but I get the same result. That makes you a genius for finding a simple workaround to an annoying problem. Thanks, cps
Okay. How did you create the table account-new. I think your table is corrupted, from the perspective of OpenOffice. Do you access the table with another toll?
Created attachment 86684 [details] Another example of the 40=58 phenomenon This file was created from scratch. I added 40 records by hand and when you open the table, it shows 58 with duplicates. Add one more record and the problem goes away.
I come back on this issue. I was not able to reproduce with your last ODB. I open Table1 and I see only 40 records
I see 76 when opening the file. But when I refresh It goes down to 40. Tested with Java 1.8 and Java 10. If I add one Row the Issue is gone completely. @ Charles. What do you mean if I add Rows by hand? Do you add them in the file with an editor or do you mean you edit them using the input field from base?
(In reply to Peter from comment #8) > I see 76 when opening the file. But when I refresh It goes down to 40. > Tested with Java 1.8 and Java 10. > > If I add one Row the Issue is gone completely. > > @ Charles. What do you mean if I add Rows by hand? > Do you add them in the file with an editor or do you mean you edit them > using the input field from base? The first example I sent was a production table, in which I had simply over-written fields that contained personal data with text from another file. Table1, by comparison, was purpose built to test the defect. I added rows one at a time through the table user interface until I had 40 records. Hope that helps. Thanks for following up. cps
(In reply to oooforum (fr) from comment #7) > I come back on this issue. > I was not able to reproduce with your last ODB. > I open Table1 and I see only 40 records Well, others have seen different numbers of records. It might be helpful if you describe the system on which you are running OO Base, as everything seems to be pointing to idiosyncrasies specific to operating systems and/or hardware. I'd like to know because if I continue to use this particular database, I'd sure like a system where the problem does not occur! Many thanks for following up. cps
changeing status from unconfirmed to confirmed. I think I can reoproduce it now and even corner some issues in the code. I have tested with Arch Linux with public release 4.1.7. I do not believe it is Hardware dependent. I checked today a personal build (AOO450m1(Build:9900) - Rev. 859e76afdd ) on trunk with debug Options enabled. This is using Ubuntu 16.04.6 LTS Please not not all Issues maybe related to the specific Issue. Error: OPropertyArrayAggregationHelper::fillHandles : property names are not sorted! From File /home/legine/AOO/main/comphelper/source/property/propagg.cxx at Line 280 Abort ? (Yes=abort / No=ignore / Cancel=core dump) Error: assertion failed! From File /home/legine/AOO/main/vcl/unx/gtk/a11y/atkwrapper.cxx at Line 874 Abort ? (Yes=abort / No=ignore / Cancel=core dump) Error: Old position is not equal to new position From File /home/legine/AOO/main/dbaccess/source/core/api/RowSetBase.cxx at Line 1137 Abort ? (Yes=abort / No=ignore / Cancel=core dump) Error: Old position is not equal to new position From File /home/legine/AOO/main/dbaccess/source/core/api/RowSetBase.cxx at Line 1137 Abort ? (Yes=abort / No=ignore / Cancel=core dump) Error: BrowseBox::ImplPaintData: SeekRow gescheitert From File /home/legine/AOO/main/svtools/source/brwbox/brwbox2.cxx at Line 960 Abort ? (Yes=abort / No=ignore / Cancel=core dump) Error: Old position is not equal to new position From File /home/legine/AOO/main/dbaccess/source/core/api/RowSetBase.cxx at Line 1137 Abort ? (Yes=abort / No=ignore / Cancel=core dump) When pressing refresh I get multiple calls of: Error: Illegal call here! From File /home/legine/AOO/main/svtools/source/brwbox/brwbox3.cxx at Line 385 Abort ? (Yes=abort / No=ignore / Cancel=core dump)