On Jun 9, 2010, at 12:51 AM, Dave Segleau wrote:
>
> On 6/8/2010 9:25 AM, Dan Kennedy wrote:
>>
>> Those pragmas should not cause a problem. Simon's referring
>> to "PRAGMA synchronous". The docs for which explain the
>> risks assumed by changing the default setting.
>>
>>
On 6/8/2010 9:25 AM, Dan Kennedy wrote:
>
> Those pragmas should not cause a problem. Simon's referring
> to "PRAGMA synchronous". The docs for which explain the
> risks assumed by changing the default setting.
>
> http://www.sqlite.org/pragma.html#pragma_synchronous
>
>
As Dan said,
On 8 Jun 2010, at 5:25pm, Dan Kennedy wrote:
> Those pragmas should not cause a problem. Simon's referring
> to "PRAGMA synchronous". The docs for which explain the
> risks assumed by changing the default setting.
>
> http://www.sqlite.org/pragma.html#pragma_synchronous
You're both right. I
On Jun 8, 2010, at 10:54 PM, Daniel Stutzbach wrote:
> On Tue, Jun 8, 2010 at 10:02 AM, Simon Slavin
> wrote:
>
>> I'm not sure whether a power-cut at a particularly bad time could
>> cause
>> something like this. The journaling mechanism built into SQLite
>> should
On Tue, Jun 8, 2010 at 10:02 AM, Simon Slavin wrote:
> I'm not sure whether a power-cut at a particularly bad time could cause
> something like this. The journaling mechanism built into SQLite should be
> avoiding it, but your combination of PRAGMAs might be defeating the
> Yes. It's quite possible to have corruption which shows only when you hit a
> particular row while using a particular index. The corruption can hide in
> the file while you carry on adding rows or searching using other indices and
> come to light only under some weird circumstance in the
On Tue, Jun 8, 2010 at 6:32 AM, Nick Shaw wrote:
> 1) File/Disk corruption by the OS. On Windows, this can happen if the
> system suffers a power loss in the middle of a write, most noticeable
> when you're writing a large amount of data to a file (I realise it
>
On 8 Jun 2010, at 3:39pm, Daniel Stutzbach wrote:
> After talking with my user a bit more, he reported that he had a power
> outage around a week prior to the error. Is it possible that some part of
> the database became corrupt in a way that didn't immediately cause any
> problems?
Yes. It's
On Tue, Jun 8, 2010 at 6:57 AM, Max Vlasov wrote:
> You didn't mention your language/development tools. It would help also.
>
The application is written primarily in Python 2.6, using the sqlalchemy
package to talk to the database.
Parts of the program are written in C
On Tue, Jun 08, 2010 at 12:32:22PM +0100, Nick Shaw scratched on the wall:
> Daniel Stutzbach wrote:
> > Are there any other known ways that the database might become corrupt?
>
> My list of possible causes would be:
> 1) File/Disk corruption by the OS. On Windows, this can happen if the
> system
On Mon, Jun 7, 2010 at 7:31 PM, Daniel Stutzbach <
dan...@stutzbachenterprises.com> wrote:
> I'm the author of a small Windows application that embeds SQLite. I'm
> currently using version 3.5.9 with PRAGMA locking_mode = EXCLUSIVE
> and PRAGMA journal_mode = TRUNCATE. I just received a crash
Daniel Stutzbach wrote:
> Are there any other known ways that the database might become corrupt?
My list of possible causes would be:
1) File/Disk corruption by the OS. On Windows, this can happen if the
system suffers a power loss in the middle of a write, most noticeable
when you're writing a
I'm the author of a small Windows application that embeds SQLite. I'm
currently using version 3.5.9 with PRAGMA locking_mode = EXCLUSIVE
and PRAGMA journal_mode = TRUNCATE. I just received a crash report from a
user with the dreaded error: "database disk image is malformed".
My application is
Anybody who is using SQLite database files
that exceed 1GiB should take note of ticket
#1432. http://www.sqlite.org/cvstrac/tktview?tn=1432
The problem has been fixed in CVS. Following
some additional testing, I will be releasing
version 3.2.6. This will hopefully occur
before Monday morning.
14 matches
Mail list logo