Trying to track down the reason for a database crashing and often becoming corrupted, I found that it was the result of 0 records being selected. Supposedly not possible.
This came down to a situation in which only summary records were selected and RemoveAllSummaries was applied.
Did I write this up correctly?
Looks right to me
Can’t have zero data records present In dB, but certainly can have none of the data records selected, during a procedure. Otherwise why have info("empty") or ifselect available which could handle this?
Wanting a statement, or a series of statements, to act on just the selected statements yet do nothing if none had been selected Is reasonable code logic which shouldn’t be banned. Having none selected after removeallsumaries may be an unantipated surprise to one coder or a branch point to another. Subsequent statements at worst should produce an error, not corrupt data. Which error could be managed within the procedure or stop the procedure. In the latter case the error stoppage may need to issue a selectall on returning to manual mode.
No, that isn’t allowed. Panorama requires that there always be at least one selected record.
If a statement in a procedure would result in zero records selected, Panorama responds by selecting ALL records (since it has no idea what subset to select). It also sets the flag for the info("empty") and ifselect operations. Also, if your code doesn’t use info("empty") or ifselect`, Panorama will automatically skip any following operations that modify the database. For example, consider this code:
select Customer = "John Smith"
field Customer
formulafill upper(Customer)
If there is no John Smith in the database, all records will be selected, but the formulafill statement will be skipped. In other words, Panorama will act as if this was the code:
ifselect Customer = "John Smith"
field Customer
formulafill upper(Customer)
else
selectall
endif
Let me put this another way. The info("empty") function will return true if the previous selection criteria matched zero records. Panorama doesn’t allow zero selected records, so it selects all, but the info("empty") function lets you know that really it should be zero selected records.
The bug that Jim Cook is reporting is that removeallsummaries doesn’t trigger this sequence. If it turns out there are no selected records, it just continues as if everything is fine. It doesn’t select all records, it doesn’t skip following fill operations, and it doesn’t set the flag used by the info("empty") function. More importantly, it doesn’t leave Panorama with a valid current record, so almost any subsequent operation, even accessing or modifying a single cell, is likely to crash or cause corruption.
Fortunately, the sequence to get into this state is quite unusual. It requires you to group the database, then do a selection that results in no data records being selected. I’ll bet 99.9% of users have never done that. Other than using the info("summary") function, you’d have to really work at it to do a selection that excludes all data records but does include summary records. For now, if you do a selection while summary records are in place, I would suggest making sure you do a select all before removing summaries.
And that is exactly the safeguard I put into the procedure by which I discovered this issue. Problem solved in that case.
Interesting! Thanks for the excellent explanation. Prior to PanX I was a regular member of the 0.1% club to work with various counts and totals. Such code has since at least mostly been rewritten to use Aggregate instead.
Just working with counts and totals wouldn’t get you into this 0.1% club. To get into that club you have to unintentionally construct a selection that excludes ALL data records, but includes at least one summary record. Trivial to do on purpose, but pretty difficult to do accidentally.
Casual search of my retired Pan6 code couldn’t prove me in the club then, but a better search of my active PanX code found one potential case. Potential because it was in a check for summary records who’s content showed that, externally to PanX, their underlying data wouldn’t be kosher. I’m not sure such bad data has occurred yet.
ifselect info("summary")=1 and ...
filesave ... ; a warning on the bad data
endif
removeallsummaries
If ifselect found nothing all would be well. But had the non-kosher data occurred and the ifselect allowed the filesave to occur I’d have had a datarecord free selection after the endif and triggered the bug. Now patched as suggested. And again, thanks for the good explanation.
Yep, I think you’re in the club. 