5454 HC corruption

[SimPLsol at aol.com]

Sarah wrote:

I am still running numerous HyperCard based systems and I do get
corruption, of two sorts. One is the 5454 error, so I would be very
interested to hear your method for avoiding this. The other is when a
single card seems to disappear and any reference to it just produces a
"No such card." error. Do you have a recipe for avoiding this type as
well?

The first thing we did, about a decade ago, was put this script in the 
closeStack path:

on closeStack
   if freeSize of this stack ≥ (the size of this stack/12)¬
   or freeSize of this stack > 100000
   then
     put "Compacting, consolidating & defragmenting "& the short name of this 
stack
     doMenu "compact stack"
   end if
   if visible of msg is true then clearMsg
   pass closeStack
end closeStack

That helped alot. 
But we were still getting about 6 of the 5454 errors annually. Once or twice 
a year we'd get a 5455 (probably the same thing, but we were never able to 
find any documentation on either). When the customer would email us the corrupted 
stack there was no way to find the problem or repeat the sequence that caused 
it. (By the way, we created a "Stack Saver" designed to move data from a 
corrupted stack to a good one, I suppose most HC developers have such a stack, if 
you do not just mail me off-line and I'll send you a copy of ours.)
The breakthrough on the 5454 came when one of our customers in New Zealand 
had a corruption first thing in the morning. They had made a good backup the 
night before so they put in a copy of the backup stack and it corrupted (but the 
original was fine).
What they were doing was a job costing on a 3,000 item/card inventory stack. 
We stepped through the script and the stack corrupted predictably on card 357. 
The code said:
repeat with i = 1 to the number of lines of fld x
     do something
end repeat
Card 357 was unique in that fld x was empty. So we tested repeats and empty 
fields. Sure enough, a repeat loop on a null set corrupts the stack with a 5454 
error.
Then we went through every line of code in our system looking for repeat 
loops on both fields and variables. We added a little test:
if fld x is not empty
then
     repeat with i = 1 to the number of lines of fld x
          do something
     end repeat
end if
We added this code throughout the system about three years ago. Since then we 
have only had one 5454 reported on the new code. Users who have continued 
working with the old code still get 5455 errors at the same rate (another reason 
for them to upgrade).
This also seemed to fix the "lost card" problem. The lost cards, in our 
experience, are generally not really lost. They are just phantoms. You can go 
forward or backward through the stack until you reach the problem card - you can't 
go the that card, right? If you try to compact the stack, the message says 
"Can't compact, stack MAY be corrupted." "MAY" is probably programmer humor, the 
stack is always corrupted. But, generally all of the records are there and 
still accessible. There was one exception, one customer had a seriously corrupted 
stack (his front counter computer was sitting over the ballast for the 
florescent lights in the display case); there were nine "lost cards" and three of 
them apparently were real records.
Just as a matter of curiosity, another customer had one of our checkbook 
stacks with a "lost card" and continued to use it that way for over a year without 
further problems.
While we are talking error numbers, do you have any insight on 160690 errors?
Hope there was some help in my long-winded reply. Good luck.
Paul Looney