, October 17, 2011 1:32 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] opinion on possible bad effects from
detachingdatabase whilst statements prepared on it.
On 17 Oct 2011, at 1:22pm, O'Neill, Owen wrote:
> the application is distributed, so while it is running it
I'm trying to hunt down an awkard bug in a multi-threaded application so
I was interested in people's opinions on whether the following is a
likely problem scenario.
- the application is distributed, so while it is running it
re-syncronises it's state with the server by
I haven't actually tried it, but just by inspection I would guess that a view
can't refer to another column within itself, so there are 2 options.
Create a second view on top of the first view. (I've not tested this - note how
the view name is aliased to just 'Patterns' because I'm
Depending on your definition of 'efficient' then this might do what you
want. (untested - might need to add or remove bracket since sqlite does
seem fussy about having what it considers to be extra ones)
INSERT OR REPLACE INTO "file_downloads" SELECT
If you were wanting to copy all of the in-memory database tables to a
file, rather than just one, then the backup api might be another way to
(I haven't used it myself but the documentation lists copying from
memory database instances to file databases as
Whilst not knowing much about the process, I have a recollection about
something in the documentation that said if sqlite thought that there
was a potential for deadlock the busy handler was never even called.
Could that explain this ?
What I usually do is work my way through binding each value to null one
at a time until it works, when it does I know I've found the column that
was previously the offending one.
- and when I say null I should really say "some known value that is
within the constraints range on the column".
On the basis of the number of times it comes up on the mailing list,
and the grounds that most 'casual' users will want Sqlite to work as
well as possible 'out the box' -
I'd like to suggest the that the default busy handler is changed from
being none to being
the 'standard' busy
I could be wrong, but even if the statement failed, and you have called
finalize, I vaguely recollect reading somewhere that (if you called
BEGIN) then you need to rollback.
Can't find the manual / wiki link to back that up at the moment.
(oh and installing a busy handler should help things -
Correct, ARM's emulate hardware floating point using software.
And it's really slow too since it forces a context switch as the
processor spots it's been given a FP operation to do and has to jump
into the fp emulation.
If you are lucky enough to have control over it & depending on the level
I'm not the expert on this, but there is an overhead to consider in
terms of the record header.
one question - the table storing the integers - was it created with one
of the data values as the primary key ?
If not then you'll have a rowid in each row too.
If that's really what you want to do then I think something along the
lines of keeping the DB in the C++ program and then using a named pipe
or socket to do the inter-processes communication between the java and
C++ programs is the way to go. - or some CORBA/SOAP like wrapper to do
The reading should be ok, but you'll have to be *really* careful how you
handle that many concurrent writers.
See the recent thread titled "shared cache mode and 'LOCKED'" which has
a discussion of topics with the same problem.
to unblock. Be
>> aware, you should also close any open cursors before yielding,
>> because open cursors will prevent write locks and you'll waste time
>> yielding for nothing.
hope this helps (and isn't incorrect).
You can get close if you put some check constraints on the columns.
I must agree with other posters that the lack of an exposed timestamp
type does feel like something of a gap.
Does anyone know if this page is still up to date with respect to when
you get "SQLITE_LOCKED" when operating in shared cache mode ?
(I'm trying to solve a two writers problem and am trying to understand
the best way to solve
I was just about to start investigating what was involved in
implementing a pragma that did just this - only to find it exists
already ! (ver 3.6.15)
(and it does function as it says on the tin)
(look at the flagPragma function "ignore_check_constraints",
: [sqlite] [Windows] Good GUI alternative to sqlite.exe?
On Fri, 23 Oct 2009 11:13:05 +0100, "O'Neill, Owen"
Thanks for the pointer.
"Version 1.2 released - 04/05/2005"
[mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Gilles Ganault
Sent: Friday, October 23, 2009 10:45 AM
Subject: [sqlite] [Windows] Good GUI
Really does depend on the query (sql) you are running.
To investigate start by looking at the explain plan
Classic "slow query" problems are table scans - where the engine has to
scan the entire
Update "table" set "columnname"='newvalue';
Time to learn some sql basics and discover the 'where' clause :-)
[mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Kavita
Run the sql
'delete from "tablename";'
if the table definition is different (different column names or data
types ) then you will need to drop the table and create a new one.
'drop table "tablename";'
if the table is huge you might get different
Personally I'd put the nodes and vertices/paths/edge between them in
separate tables. (unless you're happy with the 1 vertex between nodes
It does really get horrible if you're planning to use SQL to find
relations with a distance apart of > 1 vertex.
I have an oh so vague
I'm using sqlite on a JFFS2 file system (writing to NAND flash) so I'm
wondering what the best file system characteristics to report via the
xSectorSize and xDeviceCharacteristics methods are ?
(JFFS2 is in summary a rotating log
Mail list logo