The purpose of this setting is to help ensure the list or matrix has reasonable performance. At some point, too many rows will just cause beachballs. There’s no exact maximum number, 5,000 was more or less picked out of a hat. Depending on how many columns, or how complicated your matrix design is, you might want the limit to be higher or lower.
You cannot set this limit in the Construct template. The only way to see and modify this value is using the blueprint.
If you want to show the next 5,000 items, you need to change the selection criteria in the list or matrix. I would think that generally scrolling thru over 5,000 items probably isn’t a good user interface, you should cut down the selection to a more manageable number somehow.
Yep, understood. We’re presently working with 128 fields and so I’ve seen a beachball or two. (A rethink of the design is in progress to bring down that number of fields to something smaller. What would you suggest as a max?) I did laugh when I saw the 5,000 of of 19,000 number as it did make me realize that I was pushing it. It was not really a problem as I had already designed for a tab panel setup to segregate the records into palatable groups. Was just wondering about that number and if there was a Next -> kind of option.
I have raised the limit to 10,000 for one text list that displays an array, with currently around 8,000 lines. I do not see any slowdown in the text list scrolling or responding to clicks. The array is built and displayed in less than a second. I started using arrays for many text lists because text lists would bog down with Database Navigator at a certain size, although I don’t remember the threshold for seeing a slowdown. With some programming, the array text list can work almost identically to a list with Database Navigator enabled.
It depends on the application, which is why the option was made it configurable. In some situations (lots of fields, or a complicated matrix template) even 5,000 might be too high, in other cases 50,000 might be fine.
This is more or less how the Database Navigator feature came about. I had implemented this with arrays and realized that it could be done directly within Panorama, which makes it much easier to set up and use. But the array option is still available.
By the way, the maximum size restriction does not apply when the Database Navigator feature is used. If the database contains 100,000 records, the Text List or Matrix will display all 100,000 when this mode is used. Internally, this works the same way the data sheet works, in fact it is the same code.
By the way, one thing that will definitely cause beachballs is simultaneously opening two or more windows that display a list view of the database. You should avoid having both the data sheet and a view-as-list form open at the same time, or the data sheet and a Database Navigator text list, or any combination where two scrolling views of the database are open at the same time (it’s fine if they are for different databases).
This is not my experience. I am using the same database as the data source, with Database Navigator turned on, and the Progress Bar displays ‘5000 out of 18396’ and the list does only display those beginning records.
You should avoid having both the data sheet and a view-as-list form open at the same time, or the data sheet and a Database Navigator text list, or any combination where two scrolling views of the database are open at the same time (it’s fine if they are for different databases).
Does this apply to a form with more than one text list as well? I find text lists and matrixes to be very slow when used with a search option.
The two text list scenario may be unlikely, but I use one form all the time that has just that. I’ve modified the checkbook database that I’ve used forever to have one searchable text list with all the checks, payments, etc. The second text list, also linked, selects for all the bills I haven’t paid (based on a flag set in a field). The nice thing is that clicking on the unpaid bill sets the selection to that entry for editing. However, thank goodness I usually don’t have more than a handful of unpaid bills at a time…maybe that’s why I don’t see a slowdown.
Answering the small question first–I call it a checkbook database for historical reasons, but who writes checks anymore? (well, I do, but not many). It holds info for my bank account, with electronic payments, debit card transactions, etc. The reason there are future items in there is that I use it for planning, and for capturing bill amounts as they come to me in email. It’s easy to copy the bill amount, pop open the file, choose the payee from a dropdown and paste in the amount. 30 seconds, then I can group and pay multiple bills online when I have time. I can also see whether there are troubles ahead.
As a long time heavy user of view-as-list forms for data entry (especially with the tab down feature), I felt the loss of that function. I didn’t make noise, as it was clear that the ship had sailed. Using text lists with a little programming has pretty much replaced that practice. As I got into them the fact that you can fill a text list with almost anything made them more attractive and powerful. So, yes, I’m happy with them, use them a lot, and keep finding ways to use them more.
I also have a glimmer of an idea of how much work it was to make them as usable as they are—thanks very much for that.
Thanks for the compliment. It’s very customized to me. Along with a few physical checks, I do a lot of electronic stuff (bill paying using the bank’s service), debit cards, etc. Recurring payments get their own procedure to be added every month.
It’s not my main use–that’s keeping grades in chemistry courses. With labs, there are a lot of grade inputs to manage. The requirement to integrate with learning management systems means that I have to create text files in the right format to import to communicate grades to students. Super easy for Pano once it’s set up.
Anyway, this has gone a bit off topic, but it does give me a chance to say thanks directly for making my life easier.