I have confirmed that the source of ongoing crashing issues I’ve had come from using RemoveAllSummaries without first applying OutlineLevel “Data”.
RemoveAllSummaries will work without a crash often enough to mislead recognizing it as the source. It may work just fine when used several times in a repeatedly used short call or a loop, then crash while going through the very same steps.
The SummaryLevel command will change the summary level of the current record. If you change it to “Data,” your subsequent RemoveAllSummaries won’t remove that record, because it won’t be a summary record anymore. I think it would be better to use
OutlineLevel "Data"
RemoveAllSummaries
That should make sure the data records are visible, and make the first of them active, before removing summaries.
You’re correct and I mis-wrote it here. I am using OutlineLevel “Data” in my code and for the benefit of future reader, I have corrected it in my original post.
If using RemoveAllSummaries without first applying OutlineLevel “Data” is the source of ongoing crashes, then OutlineLevel “Data” should also be inserted before RemoveSummaries 7 since RemoveSummaries 7 should be identical to RemoveAllSummaries.
Using OpenView you can see the code for RemoveAllSummaries. It first checks dbinfo( to see if there actually are any summaries, then calls RemoveSummaries 7 if there were. So if JamesCook is right his problem should affect both. I share his impression that there is an inconsistent problem here and shall try the fix he suggests. His fix is certainly workable albeit tedious if you’ve used that a lot. But then PanoramaX excels at tedious repetitive tasks. I know it is possible to write code to find and replace statements within other code because it I’ve done it on some 6 → X syntex changes. Now if I can just recall how… NOT recommended for other than bold, well backed up, coders.
There’s still instability in using outlines, but this fix has made a lot of difference for me today. A procedure I use a lot was crashing almost every time it ran, but with persistence I could keep relaunching and running it until it worked. Today it has worked nearly every time which is a huge improvement.
I hate to rain on your parade, but the removesummaries statement absolutely does not care whether data records are visible or not when it is run. The code in question is only a dozen lines. It looks at every record in the database, whether it is visible or not, and removes that record if it is a summary record. If the record is a data record, it is ignored.
Just in case I was missing something obvious in that dozen lines of code, I made a loop and ran it 625 times (first 25 times, then 100, then 500). It worked perfectly every time, no problem. Here’s the code I ran on a checkbook database.
for n,1,500
statusmessage n
shortcall summarytest
endloop
return
summarytest:
field Date
groupup by month
field Debit
total
outlinelevel 1
removesummaries 7
return
I did have a thought – what if your code had de-selected the summary records? So I made a slight change. After making the summary records, I deselected all of the data records.
summarytest:
field Date
groupup by month
field Debit
total
outlinelevel 1
select info("summary")>0
removesummaries 7
return
The removesummaries statement did the correct thing – it noticed that there were no visible records so it automatically did a select all after removing all of the summary records. Again, I could loop as many times as I wanted with no problem.
Obviously if you are encountering crashes then something is wrong. However, there must be some additional factor beyond the outlinelevel statement. If you are using any form windows, I would see if the problem goes away when using only the data sheet.
I’m assuming that there is no corruption in your actual data. If there is, that of course could be the source of the problem and that would be why I can’t see the same problem here. To catch that sort of problem, the next beta version of Panorama automatically checks the integrity of the data each time the database is opened and saved.
My parade is fine… especially since my ‘fix’ has two db’s working without crashes when they were crashing constantly before. You have the crash records. One small db that I use daily runs some totals for me. I would launch it, run the calculations and watch it crash over and over, until it would work. Sometimes it might have been a dozen consecutive crashes within a couple of minutes, then a successful run. No change in the data, no change in the procedure, no change in the active cell, just open and run.
Today I just ran it several times in a row and no crash at all. The only difference is the addition of OutlineLevel “Data”.
This crashes:
SelectAll
RemoveAllSummaries
Field Client GroupUp
This does not:
SelectAll
OutlineLevel “Data”
RemoveAllSummaries
Field Client GroupUp
Another database was also crashing when doing a GroupUp on a text field. It grouped the field successfully at the start of the procedure, but would crash after summaries were removed and another grouping was attempted. Adding OutlineLevel “Data” before removing the summaries has eliminated the crashing.