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:c9fa329f54736de
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 their connections, or what sort
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 for any program
tion
something|out on the wing
...because it just shouldn't exist.
-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: [sqlit
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
ret
5 matches
Mail list logo