Re: [sqlite] Installing SQLite on a Shared Platform
jpadie wrote: > 2. the linux servers are debian 2.4.28 (so they say). i read that 2.4 was > not a stable release so i am assuming they mean 2.2.x in any event With Debian 2.4.28 I think of a Debian release with kernel version 2.4.28. This means it is a Debian distribution with a self-compiled kernel. No information about Debian release. You might get some information about Debian release with cat /etc/debian_version or cat /etc/issue but the content need not to be the truth. > from this i would guess it would also use glibc2.2 and not 2.3 as you > point out the debian woody (3) uses the earlier library. The command ldd --version tells you the GNU libc version. If I remember correct, phpinfo() has a line with libc version, too. >so next thing to try is to find sqlite.so compiled with glibc.so. i have > no way of compiling things on my systems and googling does not reveal > anything. Do any of you know a source of precompiled .so files? Why you don't use one of those Linux Live CDs? You get libraries, you can decompress binary packages, pick the right files and you can compile.
Re: [sqlite] Questions to autocommit mode
[EMAIL PROTECTED] wrote: > Markus Kolb <[EMAIL PROTECTED]> wrote: >> Hello, >> >> I have some questions to autocommit mode of SQLite 3.3.4 and its >> transactions. >> >> Did I understand it right that new or changed row data is only written >> to disk when the db connection is closed with sqlite3_close? > > No. Data is guaranteed to be written to disk when you COMMIT, > and a COMMIT happens automatically after every statement in > autocommit mode. > > SQLite transactions are (among other things) Durable. That means > that all the data is safely on the disk surface before COMMIT > returns (autocommit or explicit commit). You can take an power > failure or OS crash at any point after a COMMIT and the data will > survive (assuming your disk drive doesn't get wasted - nothing > really we can do about that.) > > Where did you get the idea that data is only written to disk > on close? Is there some point in the documentation that needs > to be clarified? I got the idea from this page: http://www.sqlite.org/lockingv3.html 7.0: "By default, SQLite version 3 operates in autocommit mode. In autocommit mode, all changes to the database are committed as soon as all operations associated with the current database connection complete." "The SQL command "COMMIT" does not actually commit the changes to disk. It just turns autocommit back on. Then, at the conclusion of the command, the regular autocommit logic takes over and causes the actual commit to disk to occur." And I got the idea because my INSERTS with sqlite3_exec are not written to disk but the memory usage of my program grows with each INSERT. I am using autocommit and I call sqlite3_exec with a SQL-INSERT inside a sqlite_callback()-function which gets called for each row of a SQL-SELECT (sqlite3_exec, too). It is working but the inserts seem to stay in memory till the connection is closed and with more inserts each insert needs more time. I call my program which does many row inserts. I use the sqlite3 tool to have a look at the DB while my program is running. I do a "SELECT * FROM table;" and before my program has finished there is no new row result. Starting with an empty table it is empty until my prog has finished. If I kill my program after e.g. 5 minutes (in this time it has done many many INSERTS) there is no new data in the DB file afterwards. So again my question what can I do to get the data written to DB file or why there is this behavior? Thanks Markus
[sqlite] Questions to autocommit mode
Hello, I have some questions to autocommit mode of SQLite 3.3.4 and its transactions. Did I understand it right that new or changed row data is only written to disk when the db connection is closed with sqlite3_close? Did I understand it right that after a transaction commit, autocommit is enabled again and the data from the transaction is written to disk not before the db connection is closed like in autocommit mode with sqlite3_close? Is there a way to force a diskwrite without closing the db connection? Thanks Markus
Re: [sqlite] cannot commit transaction - SQL statements in progress
Markus Kolb wrote: > Hello, > > I open one connection to a sqlitedb and do a few successful autocommited > sqlite3_exec() calls. > Then I want to use the db handle to call another sqlite3_exec() with SQL > code for a transaction. > Before I close the connection I call again sqlite3_exec() with SQL > COMMIT to end the transaction. > This produces the sqlite error: cannot commit transaction - SQL > statements in progress > > I don't use statements and/or threading in my code but sqlite is > compiled with threading enabled. > > I don't understand why there are statements in progress? Thanks for your "very numerous" help ;) I know it in the meantime. The transaction stuff got called by accident in a callback function. The callbacks are threaded by sqlite?! Bye
[sqlite] cannot commit transaction - SQL statements in progress
Hello,
I open one connection to a sqlitedb and do a few successful autocommited
sqlite3_exec() calls.
Then I want to use the db handle to call another sqlite3_exec() with SQL
code for a transaction.
Before I close the connection I call again sqlite3_exec() with SQL
COMMIT to end the transaction.
This produces the sqlite error: cannot commit transaction - SQL
statements in progress
I don't use statements and/or threading in my code but sqlite is
compiled with threading enabled.
I don't understand why there are statements in progress?
In my code below I've used a while loop for the commit and this loops
endless, always reporting the SQL statements in progress error.
So what is going on there? What should I know?
Bye
Markus
Part my code with transaction:
strcpy(sql, "BEGIN EXCLUSIVE; INSERT INTO tbl_d (id) SELECT id FROM
tbl_o WHERE bs LIKE '32' AND bd < '1141078718' AND id NOT IN ( SELECT id
FROM tbl_d ); UPDATE tbl_o SET bs='64' WHERE bs LIKE '32' AND bd <
'1141078718'");
if ((dberr = sqlite3_exec(gdbh, sql, NULL, NULL, )) != SQLITE_OK) {
msg(MSG_ERROR, "(%d) %s", dberr, errmsg);
if (errmsg != NULL) sqlite3_free(errmsg);
strcpy(sql, "ROLLBACK");
if ((dberr = sqlite3_exec(gdbh, sql, NULL, NULL, )) !=
SQLITE_OK) {
msg(MSG_ERROR, "(%d) %s", dberr, errmsg);
if (errmsg != NULL) sqlite3_free(errmsg);
}
if (errmsg != NULL) sqlite3_free(errmsg);
return;
}
if (errmsg != NULL) sqlite3_free(errmsg);
strcpy(sql, "COMMIT");
while ((dberr = sqlite3_exec(gdbh, sql, NULL, NULL, )) !=
SQLITE_OK) {
if (errmsg != NULL) sqlite3_free(errmsg);
}
if (errmsg != NULL) sqlite3_free(errmsg);
