Subscribe to this thread
Home - General / All posts - Radian. Behaviour of scroll bar
tonyw
736 post(s)
#11-May-17 21:55

Hi, Is anyone else noticing the behaviour of the scroll bar on the right side of a Table component in Radian so that when there are more rows than will fit the screen, the vertical length of scroll bar pretty much takes up the height of the screen giving the impression there are only a few rows out of sight below when in fact there could be thousands of rows out of sight? See the attached screenshot. I'm at the top row of my table which has 26,636 rows. My screen displays 58 rows and the scroll bar visually gives the impression that there are only a few rows left out of sight below. Dragging the scroll bar down as far as it will go reveals a few more rows (now up to 59) but if I press CTRL-END, I see the rows go down to 26,636 rows. So using the scroll bar only moves me up or down in the data by one or two rows only. Normal MS-Windows behaviour is the gap below or above the ends of the scroll bar is an indication of how much more data is out of sight. Also usual MS-Windows behaviour is dragging the scroll bar to the very bottom or very top of its travel would reveal the bottom (or top) row of data. Not so in Radian, the scrolling only reveals one or two more rows. Is there a functional reason for the way the scroll bar behaves in Radian that I'm missing?

thanks

Attachments:
Scrollbar.JPG

Dimitri


7,413 post(s)
#12-May-17 07:17

Is there a functional reason for the way the scroll bar behaves in Radian that I'm missing?

Yes. It's discussed in the introductory topic on Tables and also explicitly in the Table Windows and Big Data topic.

tonyw
736 post(s)
#12-May-17 18:20

Thanks Dimitri for the link.

"Manually sifting through millions of records a table full at a time is no way to find a needle in a haystack and that's not what table windows are for in big data".

Often I receive data but don't know what is in the data. Most times there is no accompanying data catalogue or metadata. So inspecting the field names and scrolling through the data is often fruitful to understand the structure of the data. So it's less of an issue of finding a particular record but exploration to know if the data are structured to answer the question I have. I'll develop a hypothesis about the data structure and check against other sources and ask for peer review.

KlausDE

6,410 post(s)
#12-May-17 18:25

I just create a GROUP BY query and have the systematic overview and don't overlook rare data combinations.


Do you really want to ruin economy only to save the planet?

Dimitri


7,413 post(s)
#12-May-17 19:49

So inspecting the field names and scrolling through the data is often fruitful to understand the structure of the data. So it's less of an issue of finding a particular record but exploration to know if the data are structured to answer the question I have. I'll develop a hypothesis about the data structure and check against other sources and ask for peer review.

Those are all good things. Nothing about how scroll bars behave in Radian is a bar to doing them. You can do all of the above in Radian as well. It's just that scroll bars have much less utility when you are working with larger tables, especially if they are coming in from some external data source.

I'd also recommend getting familiar with table navigation shortcuts like Ctrl-End and Ctrl-Home, and using Pg Up and Pg Dn when you want to scroll up and down through a table interactively. Hitting PgDn ten or fifteen times scrolls through a heck of a lot of records.

Scroll bars can also be misleading. Someone might think "oh, I don't want to just see records from the beginning of a table, I want to jump to the middle for a different sort of sample." But that's an error because records in tables should never be assumed to be ordered. They often are, but that's a happenstance thing that no serious DBMS (not Oracle, not PostgreSQL, not DB2... etc, etc.) guarantees.

If you want to look at records in order you do a query with ORDER BY. The way to get different, casual looks at parts of a table is to launch a command window and then in an ad hoc way write tiny queries. I'll often write multiple queries in a command window, copying and pasting extras, and then highlight the one I want and hit Alt-Enter to execute just that one.

If you have a big table, the info pane will tell you how many records you have, or you can hit Ctrl-End to jump to the end and see how many records you have (and take a look at the "end" of the table...). Suppose it is 2000000 records.

Write

SELECT * FROM table OFFSET 1000000 FETCH 50;

to take a look at 50 records from the middle of the table. Like I say, there's no order to be assumed but if you think there is or just want to sample records from the "middle" of the table, do that. For more than just a few records it is way easier to jump around in a table using OFFSET and FETCH than to try to approximate locations with a scroll bar.

You can also do other queries, like Klaus suggests, to get your head around the table and the data it contains.

tonyw
736 post(s)
#14-May-17 19:19

Thanks Klaus and Dimitri, Group by works and reveals the infrequent instances. The keyboard commands for faster scrolling do the job too, I'm often looking across fields (across columns) when I'm exploring what data I've acquired.

Manifold User Community Use Agreement Copyright (C) 2007-2021 Manifold Software Limited. All rights reserved.