Hi,
I’ve got a database displays this dialog when one particular record comes into view.
I’ve tried the following:
to no avail.
Is there a way to “force delete” a records … regardless of the data in the record?
Any suggestions … so I don’t lose data in the other records?
Note: this is a shared database.
Thanks,
– Mark
Both of the things you tried should have done the trick. I don’t know of any other techniques.
You said that this happened when one particular record came into view, but how does it come into view if you have now deleted it?
I have seen situations where the database had to be forced to single user, then re-shared.
It does not delete. It “acts” like it will delete, and one of two things happen:
Bottom line: I’d like to remove the corrupted record.
I guess I could try to “slurp” all the data into a new database and hand copy all the forms and procedures … but that would be pretty time-consuming. 
Thanks
– Markj
Once you create the basic field layout for the new database all you have to do is open a View Organizer for both the old file and the new file and then drag the forms and procedures from the old database to the new one. This almost instantly creates a copy of the dragged item in the other database.
One other thing to try get the record deleted. If you can, select only that record. Then do a selectreverse followed by a removeunselected. This way the problem record will not be visible and that just might allow it to be removed. Total shot in the dark.
In that case, I would suggest trying to select all other records, then use removeunselected.
If that doesn’t work (I think it probably will), you could try selecting all other records, then export to text, then re-import, replacing the existing data.
In either case, when you do the selection, it might be necessary that the selection formula not include the numeric field that contains the corrupted data.
Good point for Panorama X, but Mark is using Panorama 6.
This worked!
Thanks, Gary! 
Yeah … the “RemoveUnselected” did the trick.
What a pain!
I’m still trying to work out how my client corrupted the data in the first place.
Any ideas on how that happens? And what I can do to pre-emptively mitigate that kind of corruption?
Thanks,
– Mark
P.S. It doesn’t get said enough: all you people who use Panorama are quick and giving with suggestions to solutions, right along with the genius who writes this stuff (Jim!) I’m really appreciative of the time expended to help out.
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.
Yeah, I figured that out. Thanks for the confirmation! 
I’m not quite sure how I got that to work, though. When I try to “Force single user…”, I get an error that it couldn’t save first, so it couldn’t convert to single user.
If I try to “Remove Sharing History…”, I’m told the database must be single user first … LOL!
Ah, cool! Thanks for the background.
– Mark
Hold down the control key and it will bypass the error check.
I knew you would appreciate it and perhaps it will be informative to someone else now or down the road.
Pasting
I have found that to be a very common cause of corruption on single user or shared databases. On a shared system it has the opportunity to effect everyone.
The issue with pasting is that characters you wouldn’t typically be able to enter by typing can be introduced. Someone can also copy a record, then paste it into a cell. That one I’ve suspected with some frequency with some users You’ve described the symptoms although certainly other causes are possible.
James: Ah, now that makes sense. I wonder if I need to disable or trap all “paste” calls and vet all data before the paste operation can complete. That sounds like a lot of work. 
Thanks!