0

obviously editing any column value will change the checksum. but saving the original value back will not return the file to the original checksum.

I ran VACUUM before and after so it isn't due to buffer size. I don't have any indexes referencing the column and rows are not added or removed so pk index shouldn't need to change either. I tried turning off the rollback journal, but that is a separate file so I'm not surprised it had no effect.

I'm not aware of an internal log or modified dates to explain why the same content does not produce the same file bytes.

Looking for insight on what is happening inside the file to explain this and if there is a way to make it behave(I don't see a relevant PRAGMA).

granted https://sqlite.org/dbhash.html exists to work around this problem but I don't see any of these conditions being triggered "... and so forth" is a pretty vague cause

Bengineer
  • 21
  • 5

1 Answers1

1

Database files contain (the equivalent of) a timestamp of the last modification so that other processes can detect that the data has changed.

There are many other things that can change in a database file (e.g., the order of pages, the B-tree structure, random data in unused parts) without a difference in the data as seen at the SQL level.

If you want to compare databases at the SQL level, you have to compare a canonical SQL representation of that data, such as the .dump output, or use a specialized tool such as dbhash.

CL.
  • 173,858
  • 17
  • 217
  • 259