Apparently false SQLITE3 Error 11- database disk image is malformed.
Quote from thejerrybryan on 2024-07-25, 9:43 pmI received the malformed disk image error while trying to update the CitationTable.CitationName field. As a source splitter, the citation name is basically meaningless, but there are screens where I see the Citation name instead of Source or or more easily than the Source name. So I make the Citation name equal to the Source name except for one character that is different so that I can tell them apart.
At some point in the past, I ran a script to set CitationTable.CitationName in that manner, and I have been setting the field manually for all new citations. Just out of curiosity, I checked to see if all my citation names were correct. Some of them were not, so I decided to run the script again. It got the error malformed image error.
Here is the script.
UPDATE CitationTable
SET CitationName = '!' || (SELECT SUBSTR(Name,2) FROM SourceTable
WHERE SourceTable.SourceID = CitationTable.SourceID)
WHERE CitationID IN
(
SELECT C.CitationID
FROM CitationTable AS C
JOIN
SourceTable AS S ON S.SourceID = C.SourceID
WHERE S.TemplateID >= 10000
)Just for testing purposes, I have reduced the script to the following, which shouldn't actually have any effect.
UPDATE CitationTable SET CitationName = CitationName
It also gets the error. I have run the simpler do nothing script against all following, and they all get the same error.
- My RM8 database.
- My RM9 database
- An RM10 database newly created by importing from RM7.
- An RM10 database newly created by exporting my full RM10 database to GEDCOM and importing back into RM10.
- An RM10 database newly created by importing using Drag and Drop from RM10 to RM10.
I created a new and empty database, added one person with one citation, and my script did not get the problem on such a reduced database.
I tried each of the other columns in CitationTable, e.g. UPDATE CitationTable SET ActualText = ActualText. The only column which produces the error is the CitationName column.
There seem to be no visible symptoms or visible adverse effects at all when I'm simply using RM10.
I'm fresh out of ideas. Does anybody have anything to suggest? Thx.
I received the malformed disk image error while trying to update the CitationTable.CitationName field. As a source splitter, the citation name is basically meaningless, but there are screens where I see the Citation name instead of Source or or more easily than the Source name. So I make the Citation name equal to the Source name except for one character that is different so that I can tell them apart.
At some point in the past, I ran a script to set CitationTable.CitationName in that manner, and I have been setting the field manually for all new citations. Just out of curiosity, I checked to see if all my citation names were correct. Some of them were not, so I decided to run the script again. It got the error malformed image error.
Here is the script.
UPDATE CitationTable
SET CitationName = '!' || (SELECT SUBSTR(Name,2) FROM SourceTable
WHERE SourceTable.SourceID = CitationTable.SourceID)
WHERE CitationID IN
(
SELECT C.CitationID
FROM CitationTable AS C
JOIN
SourceTable AS S ON S.SourceID = C.SourceID
WHERE S.TemplateID >= 10000
)
Just for testing purposes, I have reduced the script to the following, which shouldn't actually have any effect.
UPDATE CitationTable SET CitationName = CitationName
It also gets the error. I have run the simpler do nothing script against all following, and they all get the same error.
- My RM8 database.
- My RM9 database
- An RM10 database newly created by importing from RM7.
- An RM10 database newly created by exporting my full RM10 database to GEDCOM and importing back into RM10.
- An RM10 database newly created by importing using Drag and Drop from RM10 to RM10.
I created a new and empty database, added one person with one citation, and my script did not get the problem on such a reduced database.
I tried each of the other columns in CitationTable, e.g. UPDATE CitationTable SET ActualText = ActualText. The only column which produces the error is the CitationName column.
There seem to be no visible symptoms or visible adverse effects at all when I'm simply using RM10.
I'm fresh out of ideas. Does anybody have anything to suggest? Thx.
Quote from Richard Otter on 2024-07-25, 9:49 pmWhenever a script outside of RM updates, deletes or inserts to a column collated by RMNOCASE , the script must first REINDEX RMNOCASE (with the fake RMNOCAE loaded) before the modification is made
Once the database is opened in RM, the Rebuild Indexes tool must be run as the first action. I usually run confirm integrity as well, to make myself feel good.
Sorry if this is obvious.
Whenever a script outside of RM updates, deletes or inserts to a column collated by RMNOCASE , the script must first REINDEX RMNOCASE (with the fake RMNOCAE loaded) before the modification is made
Once the database is opened in RM, the Rebuild Indexes tool must be run as the first action. I usually run confirm integrity as well, to make myself feel good.
Sorry if this is obvious.
Quote from thejerrybryan on 2024-07-25, 10:47 pmThat's it. Much thanks.
Actually, it isn't obvious. The reason is that for years I have made changes to RMNOCASE columns using SQLITE via SQLiteSpy. I have never before had to REINDEX in SQLiteSpy before making such changes. But I have always had to REINDEX back in RM after making such changes. So I'm very accustomed to doing that and I understand the reasons why it has to be done. And I have previously run this exact script successfully without the REINDEX in SQLiteSpy. It's not like it's a brand new script.
As I think about it, it does seem obvious that the REINDEX is necessary in SQLiteSpy before running such scripts. What is not obvious is why such scripts ever worked for me in the past without the REINDEX in SQLiteSpy.
Oh well, I will do the REINDEX in SQLiteSpy from now on and all will be well.
That's it. Much thanks.
Actually, it isn't obvious. The reason is that for years I have made changes to RMNOCASE columns using SQLITE via SQLiteSpy. I have never before had to REINDEX in SQLiteSpy before making such changes. But I have always had to REINDEX back in RM after making such changes. So I'm very accustomed to doing that and I understand the reasons why it has to be done. And I have previously run this exact script successfully without the REINDEX in SQLiteSpy. It's not like it's a brand new script.
As I think about it, it does seem obvious that the REINDEX is necessary in SQLiteSpy before running such scripts. What is not obvious is why such scripts ever worked for me in the past without the REINDEX in SQLiteSpy.
Oh well, I will do the REINDEX in SQLiteSpy from now on and all will be well.