Alexander J. Kozlovsky
<[EMAIL PROTECTED]> wrote:
T2 will try to acquire RESERVED lock of its own, but T1 is already
holding PENDING. At this point SQLite will return to the caller with
SQLITE_BUSY return code. The only way out of this situation is for
T2 to ROLLBACK and retry the transaction fro
So, if I'm reading your message right, the 25 seconds for inserting
200 (that is only 200 messsages) into a database under win 2000 is
correct???
Perhaps it's just my uneducated opinion but your explanation sounds
bogus... Why would the folks who wrote SQLITE show it off as being
so fast
On Sep 17, 2005, at 4:35 PM, Alexander J. Kozlovsky wrote:
I want to avoid doing a two step process outside the db... I want to
insert a row only if it doesn't exist already.
IMHO, if you table T1 have a unique key, you may do this
INSERT OR IGNORE T1 VALUES(1, 2, 3);
ahhh! the conflict
If id in your example identifies a row, then by
definition it is unique (probably the primary
key). If you try to insert another row with the
same id, the insert will fail. Why not just
catch the exception or error code?
Regards
> I want to avoid doing a two step process outside the db... I want to
> insert a row only if it doesn't exist already.
IMHO, if you table T1 have a unique key, you may do this
INSERT OR IGNORE T1 VALUES(1, 2, 3);
Best regards,
Alexandermailto:[EMAIL PROTECTED]
On Sun, 2005-09-18 at 01:03 +0400, Alexander J. Kozlovsky wrote:
> Hence, SQLite deferred transactions is not serializable ones.
>
Your understanding is incorrect. SQLite does *not* release
locks in the middle of a transaction - ever. It is always
serializable.
--
D. Richard Hipp <[EMAIL PROTE
Yes, I understand now.
Thanks for explanation!
Best regards,
Alexander mailto:[EMAIL PROTECTED]
I want to avoid doing a two step process outside the db... I want to
insert a row only if it doesn't exist already. REPLACE INTO seems to
almost do the trick, however, seems like it will UPDATE if the row
already exists. I want the row to be left alone if it exists.
Am trying to figure out if
> SQLite transactions are always serializable.
Serializable mode requires two-phase locking protocol. In practice
it means all locks (for read and for write) hold until transaction
end.
Deferred transaction drop SHARED lock in middle of transaction
and replace it with RES
> T2 will try to acquire RESERVED lock of its own, but T1 is already
> holding PENDING. At this point SQLite will return to the caller with
> SQLITE_BUSY return code. The only way out of this situation is for T2 to
> ROLLBACK and retry the transaction from the beginning.
Suppose next:
1. Transa
On Sat, 2005-09-17 at 15:13 -0500, Jolan Luff wrote:
> On Sat, Sep 17, 2005 at 03:41:21PM -0400, D. Richard Hipp wrote:
> > Version 3.2.6 is now available on the website
>
> 3.2.6 does not compile on FreeBSD and OpenBSD because they do not have
> fdatasync(). AFAICT, NetBSD's fdatasync implementa
On Sat, Sep 17, 2005 at 03:41:21PM -0400, D. Richard Hipp wrote:
> Version 3.2.6 is now available on the website
3.2.6 does not compile on FreeBSD and OpenBSD because they do not have
fdatasync(). AFAICT, NetBSD's fdatasync implementation does the same
thing as fsync.
Version 3.2.6 is now available on the website
http://www.sqlite.org/
This version fixes a bug that might cause database
corruption if you VACUUM a database larger than 1GiB
but the vacuum aborts and tries to rollback.
Also in this version:
The ORDER BY and GROUP BY process was completely
Alexander J. Kozlovsky wrote:
I try to understand which standard SQL isolation level correspond with
transaction opened as BEGIN DEFERRED. I think this is "DIRTY READ",
(quite dangerous level) because deferred transactions allow
unrepeatable reads.
I believe SQLite provides the highest isolatio
Hello all!
I'm new SQLite user. Sorry for my bad English, this is not my native
language.
I try to understand which standard SQL isolation level correspond with
transaction opened as BEGIN DEFERRED. I think this is "DIRTY READ",
(quite dangerous level) because deferred transactions allow
unrepeat
On Sat, Sep 17, 2005 at 03:23:04PM +0200, Miha Vrhovnik wrote:
>
> both
> SELECT DISTINCT id, * FROM t1, map WHERE t1.id = map.idT1;
> and
> SELECT * FROM t1, map WHERE t1.id = map.idT1 AND id IN (SELECT DISTINCT idT1
> AS id FROM map WHERE d0 = 2);
sqlite> SELECT id, * FROM t1, map WHERE t1.id
Miha Vrhovnik wrote:
So How can I select DISTINCT ON 1st column OR any other.
as sqlite does not support DISTINCT ON (column1, column2, )
What does it mean to select distinct on one column only? If you have a
table with two rows
1,1
1,2
and you want to select distinct on the first column,
"Igor Tandetnik" <[EMAIL PROTECTED]> je ob 17.9.2005 16:20:03 napisal(a):
>Why did you expect the latter? DISTINCT in SELECT DISTINCT detects
>identical rows, not identical first columns. The three first rows with
>an id of 1 differ in the columns you chose not to show (specifically in
>the map.d0
Miha Vrhovnik wrote:
I think there is a bug in SELECT DISTINC. I'm using sqlite 3.2.5 dll
CREATE TABLE t1(id INTEGER PRIMARY KEY, d0 INTEGER, d1 TEXT);
CREATE TABLE map(idT1 INTEGER , d0 INTEGER);
INSERT INTO t1 VALUES(1, 1, 'dd');
INSERT INTO t1 VALUES(2, 1, 'dd');
INSERT INTO t1 VALUE
Hi!
I think there is a bug in SELECT DISTINC. I'm using sqlite 3.2.5 dll
CREATE TABLE t1(id INTEGER PRIMARY KEY, d0 INTEGER, d1 TEXT);
CREATE TABLE map(idT1 INTEGER , d0 INTEGER);
INSERT INTO t1 VALUES(1, 1, 'dd');
INSERT INTO t1 VALUES(2, 1, 'dd');
INSERT INTO t1 VALUES(3, 1, 'dd');
21 => SQLITE_MISUSE
You are using a db handle in multiple threads.
You can read this:
http://www.mail-archive.com/sqlite-users@sqlite.org/msg09910.html
Best regards,
Fri, Sep 16, 2005 at 05:34:37PM -0700: Rick Keiner wrote:
> I recently updated my system with the 3.2.5 version from 3.0.8. I con
On Thu, 2005-09-15 at 20:16 -0800, dan greene wrote:
> When I ran this program on the win2000 machine with NTFS, this loop took on
> the order of 25 seconds as reported in the second printf!
> When I ran the same program on my win98 machine, it took 1.1 seconds.
> putting a begin; and end;commit;
dan greene wrote:
So, if I'm reading your message right, the 25 seconds for inserting
200 (that is only 200 messsages) into a database under win 2000 is
correct???
Perhaps it's just my uneducated opinion but your explanation sounds
bogus... Why would the folks who wrote SQLITE show it off
23 matches
Mail list logo
