Because .docx, .xlsx, etc. are not native macOS formats, I suppose. As far as I’m aware, Windows doesn’t have a directory-disguised-as-single-file concept equivalent to the macOS package or RISC OS application directory (also used for some documents). So instead Microsoft takes a directoryful of files just like the contents of a .pandb package, compresses it to a single-file ZIP archive but gives it the extension .docx, .xlsx or whatever. More cross-platform- (and cross-filing-system) compatible but also potentially needing more time and memory when loading and saving.
Rename an .xlsx file as .zip, open it and you can examine the file structure.
I’m puzzled now. I saved a small subset of the damaged file into a database, and now I am attempting to append it to the last known good file, and I am presented with this dialog:
How do you choose the database to import? I don’t see anything like the usual system file chooser. Keystrokes aren’t accepted, in fact I can’t see any way to indicate what file I want to import.
Any ideas?
OH WAIT never mind, the file had to be open already. Should be a note on that box, saying that the imported file should be already open.
I think that’s made pretty clear in the help page for ‘Import Database’. The second paragraph begins:
‘To import another database into the current one, choose File>Import>Import Database . This opens a panel that allows you to select an open database . . .’
I read too much Bucky Fuller as a child. Also, used OverVUE and previous Panorama for too many years. It really does take a long time to retrain to a completely rewritten program. There’s nothing you can do about that, I’m sure that the Panorama X team did its best.
This is completely different from your other problem. This definitely is a Panorama message, and it is entirely Panorama code.
In the scenario you describe, this is almost certainly a hardware issue. Macs do not have ECC (error correcting) memory. If a cosmic ray comes along - boop - memory is corrupted. The message above is entirely consistent with a one bit error. To prevent this sort of corruption from permanently damaging your file, Panorama checks the database structure before it saves. If it finds a problem, it doesn’t perform the save. That means the copy of the disk does NOT get corrupted.
As described in the previous paragraph, that shouldn’t be necessary. The file on disk should not be corrupted.
I just had this same issue today — “CORRUPTED DATA in filename at record 66 cell 34, cell length exceeds record length by 82".
The 8 or 9 records I’d created in that session were lost when I reopened the file (no matter; they’re easily recreated).
So there’s nothing I did wrong? I’m a total newbie with Panorama, and the only thing I did differently today from earlier sessions was to use the Duplicate Record button a few times.
There’s nothing a user can do to corrupt data or cause this issue. Panorama checks for corrupted data in case there is a hardware problem with your system - i.e. unreliable memory. What I wrote about this almost two years ago still applies.
In the scenario you describe, this is almost certainly a hardware issue. Macs do not have ECC (error correcting) memory. If a cosmic ray comes along - boop - memory is corrupted. The message above is entirely consistent with a one bit error. To prevent this sort of corruption from permanently damaging your file, Panorama checks the database structure before it saves. If it finds a problem, it doesn’t perform the save. That means the copy of the disk does NOT get corrupted.
Fortunately this sort of hardware problem is exceptionally rare - you’ll note that no one else has mentioned this in the intermediate 20 months. However, the fact that it’s rare doesn’t help you. But what is fortunate for you is that Panorama checks for the problem before it saves the corrupted data, so your file isn’t permanently damaged beyond the handful of records that hadn’t been saved yet. If Panorama didn’t check for corrupted data, you might have permanently lost the entire database (I say “might”, but this would have been the most likely outcome).
Nope. Though I fondly recall pasting graphics made in ClarisWorks into files’ Get Info window being one of the very first things I learned how to do on a Mac Classic II in 1990 or ’91.
