A previous topic in 2018 claimed the removeALLsummaries (my user-friendly spelling) statement sometimes failed.
I’m running Pan X on OS 10.11.6
It is happening to me now. After tearing my hair out, I was able to grab these two screenshots, showing the Analyze menu losing several of its functions. I believe I quit and relaunched Pan X to restore the menu, but the removeALLsummaries statement had failed (and then worked, then failed) to work in a procedure several times before I found the menu failing.
For each database, Panorama keeps a count of what summary levels exist and how many summary records are at each record. These counts are updated whenever you group, analyze or remove summaries. It appears that somehow in your database these counts are getting out of sync with the actual database, so that the counts are zero even though there are summary records. This would cause removeallsummaries to fail (because it checks to see if there are any summaries before doing anything) and would also cause the summary related menu items to vanish. So these are both symptoms of one underlying problem.
There are only three ways to create summary records that I can think of – the Summarize and Analyze dialog, the Group Up command, and the Total command (or Average, etc.). (Really only two ways, because internally Summarize & Analyze uses Group Up.) I just retested all of them and they worked. Do you remember which one you used?
If you use the code
removesummaries 7
Panorama will ignore the counts and scan the database to remove all summaries. So if you do run into this problem, this one line of code should fix it. There’s no harm in using this instead of removeallsummaries, except that the latter will be faster if there are no summaries. Your database looks like it’s not too large so the difference would probably be milliseconds anyway.
If you can figure out what steps lead to this problem, please let me know.
One other point – it looks like you might be using summary records to figure out the sum of one field. If that’s the case, I suggest that you look into the aggregate( function, which can do this in one line of code and doesn’t require you to create and then destroy a summary record.
Panorama keeps count of summary levels and records and its count could conceivably get out of sync with the actual database… Interesting! In that case could subsequent, unfixed by removesummaries 7, summary changes potentially cause PanX to unexpectedly quit?
Yes, but if reproducible quits could become an expected quit and might on further investigation be fixable. My problems with unexplained quits in 10.2 on code that run fine on 10.1.2 seems to occur in sections with multiple summary changes. So I wondered if your answer to Dave might offer a thread I could pull.
Out of curiosity, is there any way I can tell those counts were out of sync beyond seeing the problem vanish with a change from removeallsummaries to removesummaries 7?
I have sidestepped several quits by recoding to use aggregate( or summarytable( to gather subtotals instead of summary levels. But sometimes I need to manually view variously coded grouped selections of data, which usually worked in 10.1.2. I’ve had an unexpected quit there in 10.2, but haven’t had time yet to see whether it’s a one time or recurring issue. If the latter I’d need a different workaround.
FYI, none of the code involved with summary records, grouping or analyzing has changed in the 10.2 release. Since the code hasn’t changed, I would expect 10.2 to behave exactly the same as 10.1.
No.
The counts are simply used to speed up certain operations. Instead of having to scan the entire database to find out how many summary records there are, it simply looks at the counts. There are only a handful of places these counts are used:
RemoveSummaries - quick check to see if there are any summaries
RemoveDetail - quick check to see if there are any summaries
Calculation operations (total, average, etc.) - quick check to see if a summary record needs to be added at the end
Group statements - quick check to see if we are grouping within existing groups
dbinfo( function, some options return these counts
These counts are rebuilt from scratch whenever Panorama scans the database for any reason – for example any select, sort or fill. The data itself contains all the information needed to generate these counts.
So it seems to me that the worst case is that one of these quick checks comes up with the wrong answer, as in the case of the original poster’s question. It seems very unlikely that a crash could result, as Panorama doesn’t rely on these counts when actually manipulating the database. When it is actually performing an operation such as RemoveSummaries it is ignoring these counts (actually rebuilding them) and relying on the data itself.
