I forgot to mention, since this is a shared database, you have to go a bit further. Remove Unselected only temporarily modifies the local copy of the database, it doesn’t affect the server. To permanently resolve this, you need to force the database to single user, then re-share it.
Well, it’s corruption. So obviously not intended to happen, and if there were a way to mitigate it, that would have been built in to the software.
The only theory I have is RAM failure. With the exception of the Mac Pro, Macintosh computers don’t use ECC RAM, so it is possible for bit flipping to occur, though clearly rare.
When Panorama stores an integer value it uses a variable length format. Small integers take one byte, slightly larger take two bytes, all the way up to 5 bytes (or longer for 64 bit values in Panorama X). The variable length format is kind of like Unicode, though it predates Unicode. Whenever Panorama stores an integer in the database, it converts the integer into this variable length format.
When an integer is retrieved from the database (to display, edit, or perform a calculation) it is converted back into the native integer format used by the processor. The error you are seeing is happening during this conversion back into the native integer format. Not all binary values are legal numbers in the encoded format Panorama uses. If the wrong bit got flipped, the encoded value would not be valid, and Panorama reports an error.
Panorama never manipulates the encoded numeric data. Once it is stored, it is not touched. The only thing Panorama ever does with this encoded data is to decode it and turn it back into a native integer (in Panorama 6, this the C “long” type is used for native integers). So I can’t think of a mechanism for Panorama to corrupt this data, hence my theory about dropped RAM bits.
You may wonder why Panorama doesn’t just store integer values directly in the database, using the native “long” type. Back in 1986, the primary motivation was to save memory, which was extremely precious back in those days. Also, at that time, the 68000 processor could only store long values on even byte boundaries, while a Panorama data cell can occur on even or odd boundaries.
In the long run it’s turned out that there are a couple of other advantages of encoding integers this way. Different processors have different native integer formats (big and little “endian”). The Panorama encoded integer format is independent of that, so it’s been possible for integers values in Panorama databases to transfer seamlessly between big endian (68k and PowerPC) and little endian (Intel) processors. Also, the variable length format used is extensible, so it was possible to extend it to 64 bits for Panorama X. That would have been a big problem if native integers had been used.