Re: [sqlite] Null returned from NOT NULL column thanks to undetected corruption

So I tracked down the commit which introduced the "truncated page is fine" behaviour: $ fossil info 647e3b156e uuid: 647e3b156e32e37debd60b0079fc5a52bdc9b8c8 2009-03-28 06:59:41 UTC parent: 1c6521e53b846eec2e046b1e9c04c60658b8e0e8 2009-03-27 15:26:03 UTC child:

Re: [sqlite] Null returned from NOT NULL column thanks to undetected corruption

On 13 January 2017 at 22:59, David Raymond wrote: > My view is that the general thinking of the program here is simply: "just > don't make things worse." It can't help what pragmas (ie > ignore_check_constraints, writable_schema etc) others may have turned on > for

Re: [sqlite] Null returned from NOT NULL column thanks to undetected corruption

On Fri, 13 Jan 2017 11:17:11 +0800 Rowan Worth wrote: > I wonder if this is something sqlite could catch in normal operation > and return SQLITE_CORRUPT? Or are there reasons/history which would > render this conclusion inaccurate? Not without cost. In general, it's difficult

Re: [sqlite] Null returned from NOT NULL column thanks to undetected corruption

Original Message- From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Rowan Worth Sent: Thursday, January 12, 2017 10:17 PM To: General Discussion of SQLite Database Subject: [sqlite] Null returned from NOT NULL column thanks to undetected corruption

[sqlite] Null returned from NOT NULL column thanks to undetected corruption

Hi guys, Ran into an interesting situation recently where a database was transferred via FTP and the client somehow managed to truncate the file. As a result the last page was only 337 bytes rather than the expected 1024. Surprisingly running a SELECT on the affected table works without sqlite