I can define the primary key column as not null if you think that will
help, but dumping the table reveals the ids are being assigned
sequential integers.
On Tue, Mar 24, 2009 at 11:34 PM, Jim Wilcoxson wrote:
> Not sure if it will make a difference, but in your trigger stuff
;>>>>> sqlite>
>>>>>>>>
>>>>>>>> Any ideas?
>>> Obviously, that user is not playing with a full deck. ;-)
>>>
>>
>> =
&
select id, count(id) from cards group by id having
>>>>>>> count(id)
>>>>>>>> 1;
>>>>>>> sqlite>
>>>>>>>
>>>>>>> Any ideas?
>> Obviously, that user is not playing with a full deck. ;-)
>>
>
> =
Not sure if it will make a difference, but in your trigger stuff you
explicitly coded null for the primary key value. Have you tried
changing that so that you don't specify the primary key field at all?
I can't remember from the previous post, but I think it was (or should
be) set up as
>>>>>> sqlite>
>>>>>>
>>>>>> Any ideas?
>
> Obviously, that user is not playing with a full deck. ;-)
>
=============
From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org]
Sorry, my application's files are called decks, and I unwittingly used
the wrong terminology.
Any ideas about the problem?
On Sat, Mar 21, 2009 at 2:27 AM, Griggs, Donald
wrote:
>
>> However, when I ask the user to send me their deck, I find that:
>>
> However, when I ask the user to send me their deck, I find that:
>
> sqlite> pragma integrity_check;
> integrity_check
> ---
> ok
> sqlite> select id, count(id) from cards group by id having
> count(id)
>> 1;
> sqlite>
>
> Any
Yes, but I always insert with null:
self.s.statement(
"create temporary table undoLog (seq integer primary key,
sql text)")
after insert on %(t)s begin
insert into undoLog values
(null, ...)
after update on %(t)s begin
insert into undoLog values (null, 'update %(t)s ..
etc
Does the "undolog" table, or whatever you're using in its place, have
a primary key?
On Mar 20, 2009, at 1:20 PM, Damien Elmes wrote:
> Well, those 3 x the number of tables in the Db.
>
> On Fri, Mar 20, 2009 at 3:17 PM, Damien Elmes
> wrote:
>> Yep - but only the three
Well, those 3 x the number of tables in the Db.
On Fri, Mar 20, 2009 at 3:17 PM, Damien Elmes wrote:
> Yep - but only the three listed on this page:
>
> http://www.sqlite.org/cvstrac/wiki?p=UndoRedo
>
> So they shouldn't be modifying anything in the main DB, only the temporary
Yep - but only the three listed on this page:
http://www.sqlite.org/cvstrac/wiki?p=UndoRedo
So they shouldn't be modifying anything in the main DB, only the temporary DB.
On Fri, Mar 20, 2009 at 3:13 PM, Dan wrote:
>
> On Mar 20, 2009, at 8:10 AM, Damien Elmes wrote:
>
On Mar 20, 2009, at 8:10 AM, Damien Elmes wrote:
> Unfortunately, a user has just reported the same primary key error
> message with shared cache disabled, although the freezing appears to
> have been fixed.
>
> However, when I ask the user to send me their deck, I find that:
>
> sqlite> pragma
Unfortunately, a user has just reported the same primary key error
message with shared cache disabled, although the freezing appears to
have been fixed.
However, when I ask the user to send me their deck, I find that:
sqlite> pragma integrity_check;
integrity_check
---
ok
sqlite>
Hi all,
Some of my users have been reporting strange database problems
recently, which seem to have gone away when I removed a call to
enable_shared_cache(). The problems were noticeable in at least 3.6.1
and 3.6.11, when using databases of 30MB+, and doing large updates
using pysqlite.
There
14 matches
Mail list logo