On 11 Apr 2011, at 3:59am, Guilherme wrote:
> Well, I thought that if the execution followed a plan.. I could get for
> example, the cardinality from the results until a point, say a join.
> Imagine a query with 15 joins.. the execution would make a join, than, with
> the results from this join,
>> For me, this test from test/exists.test fails if both database
>> connections are opened in WAL mode, that is if "PRAGMA journal_mode=WAL"
>> is issued right after each DB is opened.
>>
>># TABLE objects.
>>#
>>do_test {
>> sql1 { DROP TABLE IF EXISTS t1 }
>> sq
On 04/10/2011 11:43 AM, thoselai...@shaw.ca wrote:
> % package require sqlite
> couldn't load library "C:/Tcl/lib/sqlite3/sqlite3/.dll": this library or a
> dependent library could not be found in library path
>
> What is sqlite3/.dll ?
> Where did that "/" come from?
>
> The pkgindex file contain
Guilherme wrote:
> Well, I thought that if the execution followed a plan.. I could get for
> example, the cardinality from the results until a point, say a join.
I don't see how the conclusion follows from the premise. Why does "follows
execution plan" have to imply "provides ready access to the
On 11 Apr 2011, at 2:48am, Richard Hipp wrote:
> On Sun, Apr 10, 2011 at 9:36 PM, Samuel Neff wrote:
>
>> I'm sorry, my statement was misleading. I'm referring to immediately after
>> our application is closed.
>>
>> We're seeing that even if the application is gracefully shut down, the -wal
On Sun, Apr 10, 2011 at 9:36 PM, Samuel Neff wrote:
> I'm sorry, my statement was misleading. I'm referring to immediately after
> our application is closed.
>
> We're seeing that even if the application is gracefully shut down, the -wal
> and -shm files are still there. In order to clear them
I'm sorry, my statement was misleading. I'm referring to immediately after
our application is closed.
We're seeing that even if the application is gracefully shut down, the -wal
and -shm files are still there. In order to clear them I need to open the
database files with sqlite3.exe and issue a
On 11 Apr 2011, at 2:04am, Samuel Neff wrote:
> I'm interested in hearing anyone's experiences of using WAL journal mode on
> technical support. We often have to copy databases to attach to customer
> reports and if the someone were to copy the database file while there is an
> active -wal file
I'm interested in hearing anyone's experiences of using WAL journal mode on
technical support. We often have to copy databases to attach to customer
reports and if the someone were to copy the database file while there is an
active -wal file then we would very likely be missing the most up-to-date
Guilherme wrote:
> I believed that databases in general evaluate their queries, following a
> execution plan...
> e.g. first do a table scan and apply a filter from the where clause.. than
> use the results to execute a join with other table.. than use the results to
> excute with another join..
>
Hi!
I believed that databases in general evaluate their queries, following a
execution plan...
e.g. first do a table scan and apply a filter from the where clause.. than
use the results to execute a join with other table.. than use the results to
excute with another join..
but now, from what I've
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/10/2011 07:58 AM, mcnamaragio wrote:
> Could this have caused database corruption?
SQLite does not have ordinary commands that will corrupt the database. How
to corrupt the database is listed in the doc:
http://www.sqlite.org/lockingv3.html
Thanks.
I have found that the select statement was issued inside a transaction.
Could this cause sqlite to make changes to the database? I also observed
that if I mark the database as readonly and issue a select statement inside
a transaction (what the application was doing) I get "attempt to
Thanks.
I have found that the select statement was issued inside a transaction.
Could this cause sqlite to make changes to the database? I also observed
that if I mark the database as readonly and issue a select statement inside
a transaction (what the application was doing) I get "attempt to writ
For me, this test from test/exists.test fails if both database
connections are opened in WAL mode, that is if "PRAGMA journal_mode=WAL"
is issued right after each DB is opened.
# TABLE objects.
#
do_test{
sql1 { DROP TABLE IF EXISTS t1 }
sql2 { CREATE TABLE t1(x) }
sql1 {
The test passes well if I recreate the database file anew just prior to
running it so it acts upon an empty database.
If this is what is intended, I apologize for the false alarm.
Ralf
On 10.04.2011 10:28, Ralf Junker wrote:
> For me, this test from test/exists.test fails if both database
> con
For me, this test from test/exists.test fails if both database
connections are opened in WAL mode, that is if "PRAGMA journal_mode=WAL"
is issued right after each DB is opened.
# TABLE objects.
#
do_test{
sql1 { DROP TABLE IF EXISTS t1 }
sql2 { CREATE TABLE t1(x) }
sql1 {
17 matches
Mail list logo
