Yesterday, for the second time, a user has reported repeated crashing with shared database BP. When I opened BP, I immediately received the alert reporting corrupt data. (This same thing happened six weeks ago.) The crashing began when running a procedure that transfers data from a standalone DB to BP. (There was some uncertainty on the user’s part of what she did immediately before the first in the series of crashes.). Admittedly, I need more detailed information about the steps preceding the first crash and subsequent crashes. (According to the Help Page on Integrity Checks, the DB might have some corrupt data from some unknown amount of time before crashing starts, so that makes it difficult to consider when the corruption occurred.)
Based on what I saw, it appears that the data became corrupted on her computer and was saved to the server and then transferred to me. If I could use the Integrity check feature to avoid that, I would certainly do it. Any ideas on how to avoid spreading the corruption via the server? (I see that at least one other person (panaca on 4/8) has reported what was believe to be corrupted server data; but that was before integrity checks.)
Just to complicate matters, I obtained a copy of her DB and dbinfo(“datacorruption”) is empty, meaning it found no data structure corruption.
The user has Time Machine running, and we restored a copy of the DB from that, but since the server was corrupted, we had to detach and discard the server copy (is that true?) Then I was unsure of how to identify the latest uncorrupt copy from Time Machine. We used the one the the end of the previous day and that worked to get a stable uncorrupted copy, but a significant amount of work was lost as a result. Any ideas about how to identify the latest uncorrupt copy of the DB?
The corruption message gives the record and cell number of the corrupt data. Is there anything to be done with that information? Is the record number the same as the serverrecordid? Could it just be deleted?
Finally, if corruption is a rare event caused by factors unrelated to PanX procedures, why would two cases of corruption occur within six weeks on the same computer performing similar operations? The coincidence would be far less likely: if the chance of this external corruption is x percent, then the probability of two them is x squared if they are independent events. The alternative hypothesis is that something has run amok during a PanX procedure leading to the corruption. This hypothesis does not conclude that the problem lies in Panorama; it could just as well lie in hardware or Apple code.