Issue 22831 - Scroll Slider scrolling of large database tables stops at record 40
Summary: Scroll Slider scrolling of large database tables stops at record 40
Status: CONFIRMED
Alias: None
Product: Base
Classification: Application
Component: code (show other issues)
Version: OOo 1.1 RC4
Hardware: PC All
: P4 Major with 6 votes (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
: 120785 122264 122634 122788 (view as issue list)
Depends on:
Blocks:
 
Reported: 2003-11-25 13:30 UTC by bryancole
Modified: 2017-11-13 22:28 UTC (History)
14 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---
jsc: 4.0.1_release_blocker-


Attachments
Screenshot of refresh display problem (283.21 KB, image/jpeg)
2014-03-02 23:47 UTC, mgroenescheij
no flags Details
Test Kit (12.72 KB, application/x-zip-compressed)
2014-03-03 09:39 UTC, Rainer Bielefeld
no flags Details
database dump and odb file (191.16 KB, application/x-zip-compressed)
2014-03-04 09:14 UTC, mgroenescheij
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description bryancole 2003-11-25 13:30:19 UTC
When you open a _large_ database table in the DataSources View, the right-hand
vertical scroll-bar (for the table) doesn't reflect the true size of the table.
Thus, if the user then drags the scroll-bar to the bottom of it's range, the
table is only scrolled by a few percent (instead of being scrolled to it's end,
as would be expected). After the scrollbar is released, it partially re-adjusts
it's size such that draging it to the bottom again once more scrolls the table
by a small fraction. Thus the use must drag and drop the scroll bar again and
again until they eventualy reach the end of the table.

This is a serious UI problem!

Yes, *I* know you can use the '>|' buttom in the database navigation bar, but
most new users will automatically try using the scrollbar to get to the end of
the table and a number of my users have expressed irritation at this 'little'
defect.
Comment 1 Frank Schönheit 2003-11-25 15:08:14 UTC
this has already been requested as issue 19402, and marked as invalid
- for a justification see there.

I doubt that we will implement it the way it's proposed here (again,
for the justification for the current behavior see issue 19402), there
could be other solutions. So normally, I would close the issue as
WONTFIX or INVALID. However, to give people the chance to express
their opinion about this, e.g. by voting, I leave the issue open. A
large number of votes may cause a reconsideration of the problem.

However, I change the priority according to
http://www.openoffice.org/issues/bug_status.html#priority, and target
the it to "OOo Later", since the chance that we will do something
about it in a forseeable future is rather low, sorry.
Comment 2 Frank Schönheit 2003-11-25 15:12:31 UTC
accepting - only because "NEW" issues generate annoying reminder
mails, I do not plan to fix it in a forseeable future.
Comment 3 hans_werner67 2004-02-02 12:29:22 UTC
change subcomponent to 'none'
Comment 4 rafaelda 2005-02-13 03:26:31 UTC
Well, despite all the explanations i still would like to se it implemented. So
I'll vote for it.
Comment 5 ptorley 2012-09-06 05:53:58 UTC
When you open your database to view table. The scrolling malfunctions this also happens when in the writer when creating envelopes using a database.
Example whn youn scroll down through the records all records will appear normal when scrolling backup randomly a record will start to multiply itself over and over again. This will also produce multiples lettters to a particular record in writer whne linked with datatbase if you select to start from say record 100 to 250 and scroll down to 250 then back up. You often get this multiple affect happening. The fault is with the databse as it happens in the database alone when scrolling up and down through records. I have only noticed this on the latest version as of 6/9/12.

Cheers Paul
Comment 6 Rainer Bielefeld 2013-06-29 15:19:08 UTC
Still Reproducible with "AOO 4.0.0-Dev – English UI / German locale [AOO400m2(Build:9701)  -  Rev. 1495357 Rev.1495357  2013-06-23]" on WIN7 Home Premium (64bit)", Common 4.0-dev User Profile:

0. Launch AOO
1. If not alreadi available in menu 'Tools -> Options -> Base -> Databeases' 
   register a new Database with hundreds or thousands of records
2. Open new Writer document
4. <f4> for Data Sources
5. In your test database select a table with hundreds or records
   In the record row headings in row 1 you see a little green arrow marking
   selected first record, and in the Data sources status bar you see something  
   like "Record 1 of 40"
6. With vertical Data Sources scroll slider scroll down
   Expected: you reach last record
   Actual: Scrolling stops at record 40. Although now is shown "Record 40 of 67"
           or similar you can not continue scrolling, even not with 'scroll down
           button' at bottom end of vertical scroll bar. You will have to scroll
           up 1 record (or more) up with 'Scroll up button' before you can 
           scroll down with  'scroll down button' (until last record if you 
           want) or with
           scroll slider, what will stop again after dome records.

Additional Info:
----------------
LibreOffice: Bug has been fixed
Status and Assignee back to list because
Comment 7 Rainer Bielefeld 2013-06-29 17:50:21 UTC
*** Issue 122634 has been marked as a duplicate of this issue. ***
Comment 8 Rainer Bielefeld 2013-07-21 05:24:56 UTC
*** Issue 122788 has been marked as a duplicate of this issue. ***
Comment 9 Rainer Bielefeld 2013-09-16 11:27:02 UTC
I revise my opinion that this one is a MINO one. Every time I want to add a recipient address to a letter I get that "no record found" message, it's really annoying. Now after 10 years we should do a serious attempt to get a fix, this bug holds up to ridicule  AOO for professional office users.

I think a 4.1.0 showstopper flag would be appropriate, but that's not available.
Comment 10 jsc 2013-09-16 15:10:26 UTC
decline showstopper request

But I agree that we should try to fix this for AOO 4.1
Comment 11 Rainer Bielefeld 2013-09-22 10:27:13 UTC
*** Issue 120785 has been marked as a duplicate of this issue. ***
Comment 12 Rainer Bielefeld 2013-09-22 10:27:16 UTC
*** Issue 122264 has been marked as a duplicate of this issue. ***
Comment 13 Matthieu Riolo 2013-10-11 16:15:46 UTC
I could fix that bug with a patch from libreoffice (see link bellow). 

As it's licensed under MPL, I think we need to fix this, but not using Lionel's patch.


The Libreoffice commit id is e581bef6dfc03d0bab9de1485c6f6cdcd034d581.

---------------------------------------------

http://www.mail-archive.com/libreoffice@lists.freedesktop.org/msg34982.html


Greetz Matthieu
Comment 14 Rainer Bielefeld 2014-01-10 07:02:06 UTC
*** Issue 124007 has been marked as a duplicate of this issue. ***
Comment 15 Rainer Bielefeld 2014-01-10 07:08:02 UTC
It's ridiculous that OOo / AOO has this bug since more than 10 years.
Comment 16 Andre 2014-01-16 12:07:17 UTC
Hm, I can not reproduce this bug.  I created a new database with a table that has 60 entries.  Then I create a text document, press F4, and select the table.
It is true that the number of rows/entries is displayed as 40* (where the start apparently means 'more than 40').  When I scroll down, either via the scroll bar handle or via the scroll down button of the scroll bar, the true size (60) is displayed about when I reach row 40.  Then the scroll bar is updated and I can scroll down to the last row.  All of that while I still scroll down.

Am I doing anything wrong?
Comment 17 Rainer Bielefeld 2014-01-16 12:33:32 UTC
(In reply to Andre from comment #16)

> Am I doing anything wrong?
A Quick test with a Database with 2000+ Records showed:
(a) Status bar below records shows !Record 1 of 40" after I
    started with <f4> in Writer document
(b) Vertical scroll down stops first at reord 63!!, so may be your database 
    is 4 records too short ?
(c) every up and down of database vertical scroll slider will increase range of 
    scrollable Rrecords:
    up,    down
     84    107
    128    151
    172    195
    216    239
    and so on, +44 for every move
Comment 18 Andre 2014-01-17 16:00:08 UTC
Yes, with a slightly larger database I can reproduce the problem.
Comment 19 mgroenescheij 2014-03-02 23:47:35 UTC
Created attachment 82772 [details]
Screenshot of refresh display problem
Comment 20 mgroenescheij 2014-03-02 23:51:38 UTC
What I read there are two different problems

In Comment 1 we read:
> When you open a _large_ database table in the DataSources View, the
> right-hand vertical scroll-bar (for the table) doesn't reflect the true size
> of the table.

This is because the we retrieve a preset number of records at a time.
The reason behind this is that you don't need to see 2000+ records and it
reduces the network traffic when you connect to an external database.

In Comment 5 we read:
> Example whn youn scroll down through the records all records will appear
> normal when scrolling backup randomly a record will start to multiply itself
> over and over again. This will also produce multiples lettters to a particular
> record in writer whne linked with datatbase if you select to start from say
> record 100 to 250 and scroll down to 250 then back up. You often get this
> multiple affect happening. The fault is with the databse as it happens in the
> database alone when scrolling up and down through records.

This is a display or refresh problem while scrolling trough many records.
This problem occurs (in my case) when I opened an other window on top of it
and later continue working with the Base application.

The first Comment is annoying while the second problem is a real bug.
See screenshot uploaded of record with unique ID 233 multiple times.
Comment 21 Martin Senftleben 2014-03-03 05:11:09 UTC
(In reply to mgroenescheij from comment #20)
> 
> This is because the we retrieve a preset number of records at a time.
> The reason behind this is that you don't need to see 2000+ records and it
> reduces the network traffic when you connect to an external database.

Sorry, but I find this argument extremely stupid.It#s correct that I don't need to *view* all records at once, but I need to be able to access them immediately. I have reported a similar bug elsewhere, which was marked as duplicate, but described rather differently. My report shows how vital a fix is. Generally when I access my databases (in form view) I look for a specific record. Generally I start the search and get the response: record not found. Then I close the search dialogue and go the end of the database, to have all records visible to the search engine. Then it works and the searched records are found. However, this is not the way how you work. When you want to search a database, you access it and then search. And not: access it, go to the last record, and then search. This behaviour is plain nonsense and needs to be fixed ASAP.
Comment 22 mgroenescheij 2014-03-03 06:04:36 UTC
(In reply to Martin Senftleben from comment #21)

> Sorry, but I find this argument extremely stupid.
It is not an argument, it's just an observation.
The purpose of my comment was to show that we mix two complete different bugs or request for changes.
I agree totally that it is confusing and need to be changed.
Comment 23 Andre 2014-03-03 08:30:53 UTC
@Rainer Bielefeld (comment 9): Can you elaborate the "no record found" problem?

@mgroenescheij / ptorley@tpg.com.au: Can you give a more detailed description of how to reproduce the 'repaint' bug, preferrably with an attached database?

@Martin Senftleben: Please don't be so offensive.  That would make listening to your arguments more easy.


@all: Regarding the problem with the wrong number of rows: would it be a solution to ask the server for the row count without asking for individual rows?  I mean, would that be acceptably fast with the database engines and databases you use?
Comment 24 Rainer Bielefeld 2014-03-03 08:49:05 UTC
(In reply to Andre from comment #23)
I remember that we had a test where I was involved few days or weeks ago in an other Bug report where we discovered several details, but unfortunately I was not able to find that quickly. I hope that I can contribute info soon.
Comment 25 Rainer Bielefeld 2014-03-03 09:39:16 UTC
Created attachment 82775 [details]
Test Kit

Was not a separate Bug report, I only also reproduced the "Find Fails" problem during tests for Comment 17

Steps how to reproduce with server installation of "AOO 4.1.0-Dev – English UI / German locale - [AOO410m1(Build:9750) - Rev. 1565724 - 2014-02-09]" on German WIN7 Home Premium (64bit)", own separate user profile:

0. download / unzip Test Kit
1. From AOO Start Center open sample.odb
2. Database Pane click "Tables"
3. Tables Pane open "Tabelle1" with double click
4. 'Find Record' Icon will open 'Record Search' dialog
5. Search for "B800" in "All Fields", Position "anywhere ...", all
   further unchecked, [Search]
   Bug: Message: "No records ... found"
6. You may try 5. several times, will always fail
7. Tick "Search backwards", rest unchanged, [Search]
   > Now recort 799 will be found, and afterwards also all
     search forwards attempts will find if contents exists.

This test is for DUPs Bug 120785, Bug 122264, Bug 122788, what seemed to be  related to the Bug from summary here.
But in the database table view from step 3 you will not be able to reproduce the scroll slider problem.
Comment 26 Martin Senftleben 2014-03-03 10:20:04 UTC
(In reply to Andre from comment #23)
> @Martin Senftleben: Please don't be so offensive.  That would make listening
> to your arguments more easy.

I thought I'm not so offensive, but apologize in case it has been read that way. I didn't mean to offend anyone. It's hard, though, as this bug annoys me every day - and it wasn't present in LibreOffice, which I used for a period but left behind as it became buggier in other areas.
Comment 27 mgroenescheij 2014-03-04 09:12:08 UTC
(In reply to Andre from comment #23)

> @mgroenescheij / ptorley@tpg.com.au: Can you give a more detailed
> description of how to reproduce the 'repaint' bug, preferrably with an
> attached database?

Herewith the dump of the MySQL database.
I have stripped all tables views and columns not relevant to this exercise.
To repeat the problem as shown on the screen-print:
1. Import the dump in a MySQL database and grant permission to whatever
   user you want to use.
2. Create a database connection and user in the odb file
3. Open the form in the odb file and click on the scroll bar up and down.
   If you're lucky it happens after a few clicks otherwise it could take hours.
   If it takes more time just do some other work and scroll in between some task.

files attached are in a zip file bug22831 database dump and odb file.zip
Comment 28 mgroenescheij 2014-03-04 09:14:36 UTC
Created attachment 82786 [details]
database dump and odb file

See comment 27
Comment 29 Michele Salvador 2017-11-11 16:21:27 UTC
I opened the Issue 127591 for the 'repaint' bug (the record that multiplies itself).
Comment 30 Keith N. McKenna 2017-11-13 22:28:24 UTC
*** Issue 127591 has been marked as a duplicate of this issue. ***