Spinning Beach Ball: would still like some help

My databases are all converts from Panorama 6. What should I be looking at first to minimize the delay of the spinning beach ball: reducing the number of fields? reducing the number of forms? reducing the number of procedures? specific items infields? speclfic items in forms? specific items in procedures? What advice can others offer?

How many fields are in your database? The data sheet will not perform well with more than about 150 fields. If you have more than that, I would recommend using the Hide/Show Fields feature so that you can work with only particular subsets of fields at a time.

The next version of Panorama (10.2) will automatically limit the data sheet to 150 fields by default (this limit can be increased in the preferences panel).

None of these are a factor, with the possible exception of Matrix objects in a form.

Interesting. I hadn’t seen that with the betas so far. I understand that data sheet performance issues with lots fields come from limitations in the Apple’s structure used to display them. It allows more fields, if one is willing to put up with the resulting unwieldy, relatively sluggish database. Dividing data into more, less wide, databases is usually a better design. The new relational tools should help divided data work together better. I’m retrofitting relations into my old dbs and just noticed one has grown to 157 fields. Will the forthcoming preference tolerate pre-existing >150 field databases or will it need to be increased for them? How about code that temporarily adds fields above the limit? I’ve added dividing the wider db to my relational todo list, but there’s plenty ahead of it.

You’re right, that is a recent change and hasn’t been released yet to beta testers. Here is the documentation:

If you want, you can change the preference to a higher value and it will work just as it has previously (i.e. you can have a databases as wide as you want but they may be sluggish, but at least you’ll be aware of the choice you are making).

The main reason this change was made was so that users would not create wide databases without understanding the consequences for performance. Basically this is a warning, not a hard limit. Most users don’t have databases that wide, but I’ve seen user databases with 500 or even 1,000 fields (the latter didn’t work well in Panorama 6 either), and the owners of these databases had no idea of the performance implications. But if you really want a wide database, you can still do it.

Keep in mind that this new limit doesn’t affect the number of fields allowed in a database, only the number of fields that can be displayed in the data sheet. So you can always add more fields, but they may not be displayed unless you up the limit. You can change the limit at any time, it doesn’t affect the data itself, only the data sheet display. For testing, I even set the limit down to 3 columns!

You should also keep in mind that as a database gets wider, adding, inserting and deleting fields are operations that especially get slower for wide databases. If possible, you might want to consider making the temporary fields permanent. You can always clear out the data from these fields when you don’t need it, but you’ll get faster performance if you don’t add and remove the actual fields.

With all the new features this year I may be forgetting some recent solutions. One of the limitations on not having all fields shown was some actions weren’t allowed, manually or programmatically, when the targeted field was hidden. The documented details of which are now hiding from me. General details are probably somewhere in Help, but might stand more cross links from related topics. Showing all fields avoided tripping over the restrictions.

Setting Favorites simplifies showing field sets manually. Either adding a ShowFavoriteFields "Favorite_Name" statement, or adding “Favorite”,“Name” (option, values) to ShowFields would simplify that programmatically. Similar statements for PanX’s favorites in Find/Select, etc. would also be nice. Probably not high priority, but perhaps easy enough to implement anyway.

That’s true in the data sheet. But there’s no such limitation when using a form, or a secret window. For example, this code would not work in the data sheet if the Elevation field is currently hidden.

field Elevation

But you can easily make it work by using a secret window. By adding one line of code you are able to use fields that are currently hidden.

window info("databasename")+":secret"
field Elevation

The code above will work even if the data sheet is open and the Elevation field is hidden.

That’s a reasonable idea, I’ve added it to the list.

One thing you can do now is create a procedure to run a favorite by using the procedure recorder. This isn’t quite what you want because the procedure would not adjust if the favorite was changed later, but it does allow you to easily create the code to run the current configuration of any favorite.

I think that sounds very helpful. I will try the hide fields option.