Now what do I do?
Now what do I do?
More details could help, but this might be all you need; Corrupted Database? - #2 by admin
I think what you do is close the database and then re-open it. The database did not save any corrupted data (that’s the point of checking the integrity before saving), so you can open the database in an uncorrupted state.
I had no other details. It “just happened”. Nothing extraordinary was going on. I’ve never seen this before, and hope never to see it again.
I could NOT close the DB in the normal fashion. The error message popped up insistently and the only option was OK. So I had to force quit. Several more rounds of the same. I retrieved a backup copy and eventually when opening the damaged file there was a mess of stuff at the bottom, all splattered data in various fields. Record 1 cell 0 was useless info. I think a later iteration referred to record 730, but that was also useless to me. It would have been wonderful if I could have closed the DB and it didn’t save corrupted data as you suggest. But it would not close. And when forced to close, it did have corrupted data once I managed to reopen it. In other words, there are other things that happen than what you describe. If it had been that simple, we wouldn’t be having this conversation.
The only way the sequence you describe would be possible would be if you had a file that had somehow gotten corrupted on the disk, and you have turned the Database Integrity option off. In that case, Panorama won’t check the database when it opens, and it will allow the corrupted data into memory. Some Panorama operations check the integrity as they go, so eventually the problem was caught – but by that time it was too late to handle it gracefully.
If the Database Integrity option is turned on, this can’t happen. If a file is somehow corrupted on the disk, Panorama will refuse to open it. The end result is the same, you’ll have to go find a good backup copy of the file. But in the meantime, you won’t waste any time trying to work on a corrupted file, and possibly even damage another file.
No, I had not turned that off. Didn’t even know it was there.
I just got that error and when I chose to immediately close the database, I had three options Save, Revert Changes, or Cancel. None of those were allowed as Revert just gave me the same error. The only option was to Force Quit.
I did not have the ‘Save database with integrity seal’ unchecked.
Yes, and that’s why you didn’t get the same corruption error when you re-opened the database.
Certainly if a problem caused corrupted data in memory (for example a RAM error), that same problem might require a force quit. But as long as the Database Integrity option is turned on, that corruption won’t be saved to disk, so everything should be ok again when re-opening the database. Or, if the data does somehow get corrupted on the disk, Panorama will immediately detect it when opening the file and refuse to open the file.
Please re-read what I wrote. I did NOT have the checkbox Un-Checked. ie. It was checked (with integrity.)
I now have a shared database that opens fine. I can add a record. Edit a record. But If I should open a new Procedure, it then displays the Corrupted error dialog. Apparently it is coming up only when it wants to do a Save.
If I close that file again, same thing, I can open without any error. Do work, but if I try to Save, I get the error. And as I can not save, I then end up with having to Quit Panorama because only then, can I discard the changes. I can not specifically Close that database. I must Quit Panorama.
To resolve this corruption, I downloaded a new copy and all was good. The issue though is that a user will be doing work and not bother to Save until after some data has been entered that is unrecoverable to re-acquire and then attempt to Save and have to lose their work. I was under the impression that upon opening, the check would be done to ascertain that the file is corrupted. Apparently it is not checking until I choose to Save.
I did understand that and my response was based on that fact.
That is the correct impression.
No, it is checking when the database opens, and also checking each time it saves.
I’m not sure what you mean by that. Part of the save process is checking the integrity of the data. This happens whether you explicitly save or when the database is auto-saved.
That’s why there is auto-save. The frequency of auto-save is controlled by Apple but I think it is pretty frequent.
Note that when the database is saved, only the data is checked for corruption, not procedures and forms. Procedures and forms are Objective-C objects, and Panorama really has no way to check them for corruption.
Probably creating a new procedure triggered auto-save, which caused the error.
Note that when the database is opened, Panorama can check the integrity of the entire database, including forms and procedures. This is because when the database is saved, Panorama also calculates a checksum of everything, so if anything changed while it was on the disk then Panorama cries foul.
Also note that the integrity features are really for “out-of-band” problems like RAM chip errors. Most users should never see these errors. It’s been nearly a year since the integrity features were added (11 months), and in fact almost no users have ever seen these messages. If I started seeing these errors on my computer, I would be concerned that there was some sort of intermittent hardware problem. The integrity features are designed to act as a guardrail to help mitigate damage from this sort of hardware problem, but if your computer isn’t storing data reliably, nothing done in software can 100% protect against that. If you see this message it’s not a signal to quit and relaunch, it’s a signal to stop everything you are doing and track down why your computer isn’t reliably storing information. In other words, this isn’t a yellow light, it’s a red STOP light.
If you don’t want Panorama to warn you that your computer isn’t reliably storing information, then turn this feature off and you’ll be back to no warnings about this, which we all managed to live thru for decades before. I imagine you would rather have the warning.