Re: [sqlite] Transactions

> On Feb 6, 2017, at 11:08 AM, James K. Lowden wrote: > > It's fascinating, and emblematic of our times, that > something like iTunes had (or has) DBMS interaction amidst low-level > operations like capture and playback. Oh, it didn’t use a database! It was just streaming audio data from the

Re: [sqlite] Transactions

On Mon, 6 Feb 2017 09:38:20 -0800 Jens Alfke wrote: > In some cases there?d be multiple events in a second that triggered a > database write in a transaction; when this happened down in my humble > process, it could cause iTunes playback to stutter and video capture > to lose frames. You should

Re: [sqlite] Transactions

On Sun, Feb 05, 2017 at 09:41:48AM +0100, Michele Pradella wrote: > Do you think transactions are useful only when you have to do a sequence > of statements that depends on each other and you need a way to rollback > all statements if something goes wrong? or you can use transactions even > with no

Re: [sqlite] Transactions

> On Feb 6, 2017, at 12:07 AM, Hick Gunter wrote: > > The optimal number of inserts/transaction depends on your hardware setup and > who else needs access to CPU and I/O resources. Too many transactions can definitely be a problem! It depends on the OS, but the filesystem flush at the end of

Re: [sqlite] Transactions

setup and who else needs access to CPU and I/O resources. -Ursprüngliche Nachricht- Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] Im Auftrag von Michele Pradella Gesendet: Sonntag, 05. Februar 2017 09:42 An: SQLite mailing list Betreff: [sqlite] Transactions Hi

Re: [sqlite] Transactions

Michele Pradella wrote: > I have a question about transactions and SQLite: http://www.sqlite.org/faq.html#q19 Regards, Clemens ___ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sq

[sqlite] Transactions

Hi all, I have a question about transactions and SQLite: Do you think transactions are useful only when you have to do a sequence of statements that depends on each other and you need a way to rollback all statements if something goes wrong? or you can use transactions even with not interdependen

[sqlite] Transactions/locks in WAL mode

On 10 Jun 2015, at 5:42pm, Clemens Ladisch wrote: > The documentation talks about writing as the primary reason for locks, > but read-only transactions need to take a read lock. Two (automatic) > transactions imply two lock/unlock operations. True. But still a bad reason to use BEGIN and END.

[sqlite] Transactions/locks in WAL mode

Olivier Vidal wrote: > In terms of pure performance, is that there is a difference between: > > - SELECT > - SELECT > (so two read transactions) > > AND > > - BEGIN > - SELECT > - SELECT > - END The documentation talks about writing as the primary reason for locks, but read-only transactions need

[sqlite] Transactions/locks in WAL mode

ok, thank you Clemens and Kevin. another question please. In terms of pure performance, is that there is a difference between: - SELECT - SELECT (so two read transactions) AND - BEGIN - SELECT - SELECT - END olivier > Simon Slavin > 10 juin 2015 14:39 > > In a

[sqlite] Transactions/locks in WAL mode

Thank you Simon! It's the first response I get, can anyone send me the Clemens's answer please? I do not know why I have not received. I hope I did not miss other responses. olivier > Simon Slavin > 10 juin 2015 14:39 > > In addition to Clemens' excellent answe

[sqlite] Transactions/locks in WAL mode

On 10 Jun 2015, at 2:00pm, Olivier Vidal wrote: > It's the first response I get, can anyone send me the Clemens's answer > please? I do not know why I have not received. I hope I did not miss other > responses. Probably got marked by your software as spam. Check in your junkmail folder. Sim

[sqlite] Transactions/locks in WAL mode

On 10 Jun 2015, at 9:48am, Olivier Vidal wrote: > SELECT > UPDATE > In this example, the set of these commands is serialized? The two commands > act on the same snapshot? So, two commands have the same data (same > snapshot), but those data may be modified by another thread/process between >

[sqlite] Transactions/locks in WAL mode

Olivier Vidal wrote: > UPDATE > Internally, is the same thing that: BEGIN DEFERRED - UPDATE -COMMIT? Yes. > SELECT > UPDATE > In this example, the set of these commands is serialized? Assuming that you finalize the SELECT before executing the UPDATE, this is the same as BEGIN SELECT COMMIT BEGIN

[sqlite] Transactions/locks in WAL mode

Hello, some questions please about transactions/locks in a multithreaded environment, multiple applications, WAL mode, NO shared cache, NO read_uncommitted pragma: Some examples: 1- UPDATE Internally, is the same thing that: BEGIN DEFERRED - UPDATE -COMMIT? 2- SELECT UPDATE In th

Re: [sqlite] Transactions for read operations

Thanks to those who responded to my query. Simon: It will be easier to code if every page commits, regardless of whether any write operations occurred (and rollback only error) - so your answer pleased me greatly. Keith: Yes, you're right. I'm not passing a single database connection around, I'm

Re: [sqlite] Transactions for read operations

>To: General Discussion of SQLite Database >Subject: Re: [sqlite] Transactions for read operations > > >On 7 Sep 2014, at 3:49am, Keith Medcalf wrote: > >> You say "the database connection". Did you use the language >imprecisely or are you using only one database co

Re: [sqlite] Transactions for read operations

On 7 Sep 2014, at 3:49am, Keith Medcalf wrote: > You say "the database connection". Did you use the language imprecisely or > are you using only one database connection? One presumes that you may have > half-a-million pages and half-a-billion concurrent HTTP operations, in which > case you

Re: [sqlite] Transactions for read operations

As a general principle, database transactions should be held for as short a time as possible. You should start your transaction, then do all of the operations immediately that need to be mutually consistent, and then end the transaction appropriately; ideally a transaction is only open for a fr

Re: [sqlite] Transactions for read operations

On Saturday, 6 September, 2014, at 20:23, Richard Warburton inquired: >Brief: >Should transactions be used for ensuring consistency between multiple >queries? And if so, after I've finished is there a reason why I should >not call commit? >Background: >I'm using SQLite for a web service.

Re: [sqlite] Transactions for read operations

On 7 Sep 2014, at 3:22am, Richard Warburton wrote: > Should transactions be used for ensuring consistency between multiple > queries? Good idea. > And if so, after I've finished is there a reason why I should not > call commit? You should finish the transaction some way. I can see why ROLLB

[sqlite] Transactions for read operations

Hi, Brief: Should transactions be used for ensuring consistency between multiple queries? And if so, after I've finished is there a reason why I should not call commit? Background: I'm using SQLite for a web service. The database reference is passed to Page objects, which handle their specific u

Re: [sqlite] transactions do not respect delete

> Date: Tue, 6 May 2014 14:57:30 +0200 > From: Mark Lawrence > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] transactions do not respect delete > Message-ID: <20140506125730.ga23...@rekudos.net> > Content-Type: text/plain; charset=us-ascii > > > It would

Re: [sqlite] transactions do not respect delete

On Tue, May 6, 2014 at 2:59 PM, Clemens Ladisch wrote: > With the COMMIT, you told the database that the transaction succeeded > (which means that the effects of all successful statements are saved > permanently.) If you want the transaction to fail, execute ROLLBACK > instead. But that's only p

Re: [sqlite] transactions do not respect delete

Jim Carroll wrote: > BEGIN; > DELETE FROM A; > INSERT INTO A VALUES(1, "goodbye"); > INSERT INTO A VALUES(1, "world");-- fails > COMMIT; > > It would appear the DELETE was successful, and the first INSERT was > successful. But when the second INSERT failed (as it was intended to)

Re: [sqlite] transactions do not respect delete

> It would appear the DELETE was successful, and the first INSERT was > successful. But when the second INSERT failed (as it was intended to)..it > did not ROLLBACK the database. Even though the second INSERT fails, your script still calls COMMIT on an open transaction in which the DELETE and firs

Re: [sqlite] transactions do not respect delete

On Tue, May 6, 2014 at 2:31 PM, Jim Carroll wrote: > > CREATE TABLE A(id INT PRIMARY KEY, val TEXT); > INSERT INTO A VALUES(1, "hello"); > BEGIN; > DELETE FROM A; > INSERT INTO A VALUES(1, "goodbye"); > INSERT INTO A VALUES(1, "world"); > COMMIT; Sounds like you want ON CONFLICT RO

[sqlite] transactions do not respect delete

I need to modify all the content in a table. So I wrap the modifications inside a transaction to ensure either all the operations succeed, or none do. I start the modifications with a DELETE statement, followed by INSERTs. What I've discovered is even if an INSERT fails, the DELETE has still takes

Re: [sqlite] Transactions

On 2/28/2014 5:48 PM, L. Wood wrote: Is this legal? 1) Create "INSERT" prepared statement with parameters. 2) Create a second non-parameter "BEGIN TRANSACTION" prepared statement, execute it with _step(), and finalize it. 3) Attach values to the parameters of the first "INSERT" prepared stateme

[sqlite] Transactions

Is this legal? 1) Create "INSERT" prepared statement with parameters. 2) Create a second non-parameter "BEGIN TRANSACTION" prepared statement, execute it with _step(), and finalize it. 3) Attach values to the parameters of the first "INSERT" prepared statement, _step() it, _reset() it. Repeat 3

Re: [sqlite] transactions and locking

Thank you both, I now have a better understanding. Lars ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] transactions and locking

On 2 May 2012, at 12:16pm, Lars Hansen wrote: > I'm sorry I have to bother you readers but I haven't understood > http://sqlite.org/lockingv3.html chapter 7. I've answered your questions in order, but they're all interrelated, so please read them all before worrying about the first answer. F

Re: [sqlite] transactions and locking

On Wed, May 02, 2012 at 01:16:41PM +0200, Lars Hansen scratched on the wall: > Hello, > > I'm sorry I have to bother you readers but I haven't understood > http://sqlite.org/lockingv3.html chapter 7. > > 1. "In autocommit mode, all changes to the database are committed as > soon as all operations

[sqlite] transactions and locking

Hello, I'm sorry I have to bother you readers but I haven't understood http://sqlite.org/lockingv3.html chapter 7. 1. "In autocommit mode, all changes to the database are committed as soon as all operations associated with the current database connection complete." How does SQLite know when AL

Re: [sqlite] Transactions for SELECT

On 11/22/2011 05:45 PM, Baruch Burstein wrote: I will when I get the chance, but I am trying to get a list of things to try to improve my SELECT speeds. If it is one SELECT, but returning +-1 rows, it probably won't make a difference, right? No advantage in wrapping a single statement, of a

Re: [sqlite] Transactions for SELECT

On 22 Nov 2011, at 10:45am, Baruch Burstein wrote: > I will when I get the chance, but I am trying to get a list of things to > try to improve my SELECT speeds. If it is one SELECT, but returning +-1 > rows, it probably won't make a difference, right? Right. It'll do a lock, then the SELECT

Re: [sqlite] Transactions for SELECT

I will when I get the chance, but I am trying to get a list of things to try to improve my SELECT speeds. If it is one SELECT, but returning +-1 rows, it probably won't make a difference, right? On Tue, Nov 22, 2011 at 11:41 AM, Dan Kennedy wrote: > On 11/22/2011 04:34 PM, Baruch Burstein wr

Re: [sqlite] Transactions for SELECT

On 11/22/2011 04:34 PM, Baruch Burstein wrote: Do transactions speed up SELECT statements? They can a bit. If you put 10 SELECT statements in a transaction SQLite only has to lock and unlock the database file once. If you run them outside of a transaction the db is locked and unlocked 10 times

[sqlite] Transactions for SELECT

Do transactions speed up SELECT statements? -- Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. - Rich Cook __

Re: [sqlite] TRANSACTIONs

On 2 Jun 2011, at 6:01pm, Jan Hudec wrote: > - Inside one transaction, running select may or may not see data inserted or > updated in parallel. Sorry to go on about this but you underestimate the problem. Suppose you're part-way through _step()ing through the results of a SELECT and an UPDA

Re: [sqlite] TRANSACTIONs

On Wed, Jun 01, 2011 at 19:23:16 +0100, Simon Slavin wrote: > On 1 Jun 2011, at 7:12pm, Jan Hudec wrote: > >> Do not update a table if there is some select statement currently > > > > Actually insert, update and delete are OK. Drop and alter table are > > a problem. > > Pavel is right. He left

Re: [sqlite] TRANSACTIONs

On 1 Jun 2011, at 7:57pm, Robert Myers wrote: > What about the I of ACID? The select should have an implicit transaction > around it. That would violate the SQL standard which says you can SELECT data which you haven't committed yet. Actually the bit of ACID you want for SELECT is really the '

Re: [sqlite] TRANSACTIONs

> What about the I of ACID? The select should have an implicit transaction > around it. No, it shouldn't. It can be a part of some other transaction. I in ACID means Isolation of transactions, not Isolation of select statements. Otherwise there would be no way for select statement to read uncommit

Re: [sqlite] TRANSACTIONs

On 6/1/2011 1:47 PM, Pavel Ivanov wrote: >> Actually, you do know what SQLite does without knowing the internals. It >> claims to be serializable and ACID >> (http://www.sqlite.org/transactional.html), therefore it's fine. > "Serializable" there means that once transaction is started statements > w

Re: [sqlite] TRANSACTIONs

> Actually, you do know what SQLite does without knowing the internals. It > claims to be serializable and ACID > (http://www.sqlite.org/transactional.html), therefore it's fine. "Serializable" there means that once transaction is started statements won't see any data committed in other transactio

Re: [sqlite] TRANSACTIONs

On 6/1/2011 1:23 PM, Simon Slavin wrote: > On 1 Jun 2011, at 7:12pm, Jan Hudec wrote: > >> On Wed, Jun 01, 2011 at 10:17:02 -0400, Pavel Ivanov wrote: From within a BEGIN TRANSACTION and END TRANSACTION block, should I not update the same row in a table more than once? >>> You can update

Re: [sqlite] TRANSACTIONs

On 1 Jun 2011, at 7:12pm, Jan Hudec wrote: > On Wed, Jun 01, 2011 at 10:17:02 -0400, Pavel Ivanov wrote: >>> From within a BEGIN TRANSACTION and END TRANSACTION block, should I not >>> update the same row in a table more than once? >> >> You can update it as many times as you need. >> >>> Wha

Re: [sqlite] TRANSACTIONs

On Wed, Jun 01, 2011 at 10:17:02 -0400, Pavel Ivanov wrote: > >  From within a BEGIN TRANSACTION and END TRANSACTION block, should I not > > update the same row in a table more than once? > > You can update it as many times as you need. > > > What are the exact limitations on what I can do during

Re: [sqlite] TRANSACTIONs

>  From within a BEGIN TRANSACTION and END TRANSACTION block, should I not > update the same row in a table more than once? You can update it as many times as you need. > What are the exact limitations on what I can do during a Transaction? Do not update a table if there is some select statement

[sqlite] TRANSACTIONs

Hey guys, thanks for all the help so far today. From within a BEGIN TRANSACTION and END TRANSACTION block, should I not update the same row in a table more than once? What are the exact limitations on what I can do during a Transaction? Thanks, Ian

Re: [sqlite] Transactions while using prepare and step

On 2 Dec 2010, at 7:38pm, cricketfan wrote: > { > Select a from tbl1 where b='yyy' c ='xxx' limit i offset (i + 1) ; > Update tbl1 set e=1 where a = some value from the select; > i = i + 1 > } There doesn't appear to be any purpose to anything but the UPDATE command. Can you not do

Re: [sqlite] Transactions while using prepare and step

> Another question - What kind of impact does a limit clause have? The columns > being used in the where clause are indexed. My current design is bad, I am > forced to use limit to get one row at a time. Since I have an index the > impact should be minimal. Please let me know if I am wrong. You wr

Re: [sqlite] Transactions while using prepare and step

I have 2 threads in my program can someone take a look at them and provide some comments Pseudo code for thread 1 (a is the primary key) Thread1() { insert into tbl1(a,b,c,d,e,f,g,h,i,j,k); } So my pseudo code is(b and c have an index, a is primary key) Thread2() { sleep(200); prepare; while(step)

Re: [sqlite] Transactions while using prepare and step

On 2 Dec 2010, at 4:39pm, Pavel Ivanov wrote: > I didn't see in OP's email any information on whether he updates the > same rows or same table as he selects, so I'd say this statement is > too harsh in general case. While select is executing you shouldn't > update the same rows that were returned

Re: [sqlite] Transactions while using prepare and step

> Makes no difference.  Doing an UPDATE inside your SELECT violates the rule no > matter how you structure your transaction.  A SELECT is a single operation > and you can't do anything else until it is finished. I didn't see in OP's email any information on whether he updates the same rows or sa

Re: [sqlite] Transactions while using prepare and step

On 2 Dec 2010, at 3:44pm, cricketfan wrote: > Hello I have a basic question and would be glad if someone can answer it. I > understand that if we have "BEGIN TRANSACTION" and "END TRANSACTION" then > the transaction(s) within that block would be committed, number of > transactions could be 10,100

[sqlite] Transactions while using prepare and step

Hello I have a basic question and would be glad if someone can answer it. I understand that if we have "BEGIN TRANSACTION" and "END TRANSACTION" then the transaction(s) within that block would be committed, number of transactions could be 10,100,1000 or 1. . Otherwise, SQLITE by default co

Re: [sqlite] SQLITE transactions failing with multiple threads

On 30 Nov 2010, at 8:11pm, cricketfan wrote: > Drake, I am using SQLITE in threadsafe mode. Transaction inside another > transaction isnt that equivalent of nested transactions? Should that be > allowed? I have no problem opening another handle but just trying to > understand the intricacies, tha

Re: [sqlite] SQLITE transactions failing with multiple threads

> sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > -- View this message in context: http://old.nabble.com/SQLITE-transactions-failing-with-multi

Re: [sqlite] SQLITE transactions failing with multiple threads

Quoth cricketfan , on 2010-11-30 12:11:52 -0800: > Drake, I am using SQLITE in threadsafe mode. Transaction inside another > transaction isnt that equivalent of nested transactions? Should that be > allowed? SQLite has named savepoints, but not nested BEGIN transactions. It's hard to tell what ex

Re: [sqlite] SQLITE transactions failing with multiple threads

llelism in the modes where it works. Aside from that, transaction > state is bound to a handle; you're starting a transaction and then > trying to start another one inside it. > > Open two handles instead. > -- View this message in context: http://old.nabble.com/SQLITE-transac

Re: [sqlite] SQLITE transactions failing with multiple threads

On 30 Nov 2010, at 3:49pm, cricketfan wrote: >I have 2 threads in my program, 1st thread is doing inserts into a > table and 2nd thread is trying to update the already inserted columns. > 1. I have bundled the 1000 inserts per transaction in 1st thread. > 2. When I try to start a transac

Re: [sqlite] SQLITE transactions failing with multiple threads

Quoth cricketfan , on 2010-11-30 07:49:36 -0800: > Also not that both threads are > using the same handle passed by main. No, don't do that. Using the same handle in two threads concurrently can break depending on the SQLite threading mode, and will gain you no parallelism in the modes where it w

[sqlite] SQLITE transactions failing with multiple threads

. -- View this message in context: http://old.nabble.com/SQLITE-transactions-failing-with-multiple-threads-tp30340806p30340806.html Sent from the SQLite mailing list archive at Nabble.com. ___ sqlite-users mailing list sqlite-users@sqlite.org http

Re: [sqlite] Transactions + .read

On 31 Mar 2010, at 6:39pm, Kevin M. wrote: >>> So, is there an API or query I can run to load an sql file all in one go >>> (one transaction) without having to read in the file manually and query one >>> line at a time? > >> No, sorry. That's what programming languages are for. Open the file

Re: [sqlite] Transactions + .read

>> Actually I was wanting to put that into a program. > I don't know how I guessed that but I'm feeling really smug now. I'm feeling very amused by your smugness ;-) >> So, is there an API or query I can run to load an sql file all in one go >> (one transaction) without having to read in the f

Re: [sqlite] Transactions + .read

On 31 Mar 2010, at 4:48pm, Kevin M. wrote: >> Warning: From your phrasing it's possible you're thinking of putting a >> '.read' command into your program. The '.read' command is only a command to >> the command-line tool. It's not a function of SQLite, and you can't submit >> it as a query i

Re: [sqlite] Transactions + .read

> Warning: From your phrasing it's possible you're thinking of putting a > '.read' command into your program. The '.read' command is only a command to > the command-line tool. It's not a function of SQLite, and you can't submit > it as a query in your program. > Simon. Actually I was wanti

Re: [sqlite] Transactions + .read

On 31 Mar 2010, at 4:21pm, Kevin M. wrote: > Hopefully I'm not duplicating a question, but I looked on sqlite.org and did > not find the answer... > > Will this: > BEGIN TRANSACTION; > .read somefile.sql > END TRANSACTION; > > Put everything in the sql file into one transaction? Or do I need

[sqlite] Transactions + .read

Hopefully I'm not duplicating a question, but I looked on sqlite.org and did not find the answer... Will this: BEGIN TRANSACTION; .read somefile.sql END TRANSACTION; Put everything in the sql file into one transaction? Or do I need to put the BEGIN/END TRANSACTION statements in the sql file it

Re: [sqlite] transactions in one thread

Charles Samuels wrote: > I need to be able to see the committed version of a database while a > new transaction is in the works. I would like to open the same > database file twice in a single thread, start a transaction on one of > the database connections, make a few writes to that database, the

[sqlite] transactions in one thread

I need to be able to see the committed version of a database while a new transaction is in the works. I would like to open the same database file twice in a single thread, start a transaction on one of the database connections, make a few writes to that database, then on the other database conn

Re: [sqlite] Transactions and attached databases

Hi Donald, On Feb 25, 2009, at 3:39 PM, Griggs, Donald wrote: > Greetings, Tito, > > Did you see page: >http://www.sqlite.org/lang_attach.html > > > Transactions involving multiple attached databases are atomic, > assuming > that the main database is not ":memory:". > > It then goes on to s

Re: [sqlite] Transactions and attached databases

Hi Donald, On Feb 25, 2009, at 3:39 PM, Griggs, Donald wrote: > Greetings, Tito, > > Did you see page: >http://www.sqlite.org/lang_attach.html > > > Transactions involving multiple attached databases are atomic, > assuming > that the main database is not ":memory:". > > It then goes on to s

Re: [sqlite] Transactions and attached databases

-Original Message- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Tito Ciuro Sent: Wednesday, February 25, 2009 6:36 PM To: sqlite-users@sqlite.org Subject: [sqlite] Transactions and attached databases Hello, If I attach one or more

[sqlite] Transactions and attached databases

Hello, If I attach one or more databases and wrap a series of operations which affect some/all of them, would ROLLBACK or COMMIT treat these operations atomically? For example: Open database 'foo'; Attach database 'bar' as a1; BEGIN TRANSACTION; INSERT INTO main.some_table ... ;

Re: [sqlite] Transactions on attached databases

It's a very useful API, thanks a lot. -- Marco Bambini http://www.sqlabs.net http://www.sqlabs.net/blog/ http://www.sqlabs.net/realsqlserver/ On Dec 12, 2008, at 5:26 PM, D. Richard Hipp wrote: > > On Dec 12, 2008, at 11:16 AM, Marco Bambini wrote: > >> I have two databases, db1 and db2. >>

Re: [sqlite] Transactions on attached databases

On Dec 12, 2008, at 11:16 AM, Marco Bambini wrote: > I have two databases, db1 and db2. > At some point I attach db2 to db1 as 'destdb' then I do: > > sqlite3_exec(db1, "BEGIN", ...); > sqlite3_exec(db1, "INSERT INTO destdb.table1 SELECT * FROM > main.table1", ...); > sqlite3_exec(db1, "INSERT IN

[sqlite] Transactions on attached databases

I have two databases, db1 and db2. At some point I attach db2 to db1 as 'destdb' then I do: sqlite3_exec(db1, "BEGIN", ...); sqlite3_exec(db1, "INSERT INTO destdb.table1 SELECT * FROM main.table1", ...); sqlite3_exec(db1, "INSERT INTO destdb.table2 SELECT * FROM main.table2", ...); sqlite3_exe

Re: [sqlite] Transactions and Threads

Shawn Wilsher <[EMAIL PROTECTED]> wrote: > I'm looking to clarify the behavior of transactions when it comes to > threads. When using the same sqlite3 object, and you begin a > transaction on one thread, does it also group work that is being done > on another thread until you end the transaction?

[sqlite] Transactions and Threads

Hey all, I'm looking to clarify the behavior of transactions when it comes to threads. When using the same sqlite3 object, and you begin a transaction on one thread, does it also group work that is being done on another thread until you end the transaction? Or is it the case that each thread can

[sqlite] Transactions on a shared database connection

With SQLite 3.5.1, when a connection is shared between two threads, if the second thread attempts to begin a transaction while a transaction is in progress on the first thread, sqlite3_exec( "begin transaction" ) returns SQLITE_ERROR with a status message "cannot start a transaction within a transa

Re: [sqlite] Transactions across attached databases

"Nakarada, Bob" <[EMAIL PROTECTED]> wrote: > Could someone definitively answer the following question about version > 2.8 of SQLite and transactions on an attached database? > > Is this expected behaviour? > At this point the "expected behavior" of 2.8 is whatever it does. If somebody find

[sqlite] Transactions across attached databases

Could someone definitively answer the following question about version 2.8 of SQLite and transactions on an attached database? Following is "pseudo code' for the type of transactions we issue. The statement to the table in the attached database sometimes fails with a busy error; the busy wait

RE: [sqlite] Transactions and 'library routine called out of sequence' locks the database

:) /Michael -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 9. maj 2006 12:26 To: sqlite-users@sqlite.org Subject: Re: [sqlite] Transactions and 'library routine called out of sequence' locks the database "Michael B. Hansen" <[

Re: [sqlite] Transactions and 'library routine called out of sequence' locks the database

"Michael B. Hansen" <[EMAIL PROTECTED]> wrote: > > However, I keep getting 'library routine called out of sequence' at > random interval. > This is caused when you do things like try to use a database connection that has already been closed or try to use a prepared statement that has already b

RE: [sqlite] Transactions and 'library routine called out of sequence' locks the database

t the problem with SQLite continues. -Original Message- From: Dennis Cote [mailto:[EMAIL PROTECTED] Sent: 8. maj 2006 17:12 To: sqlite-users@sqlite.org Subject: Re: [sqlite] Transactions and 'library routine called out of sequence' locks the database Michael B. Hansen wrote: >

Re: [sqlite] Transactions and 'library routine called out of sequence' locks the database

Michael B. Hansen wrote: I use my own global locking-mechanism, so only one connection can be opened at one time. Michael, Is it possible that your "own" locking mechanism is failing? You haven't said how the locks are implemented, and getting mutual exclusion stuff right in roll your own

[sqlite] Transactions and 'library routine called out of sequence' locks the database

Hi, I have this problem - that keeps hunting me. I use SQLite 3.3.5 - with all queries, updates and inserts in transactions. I use my own global locking-mechanism, so only one connection can be opened at one time. However, I keep getting 'library routine called out of sequence' at random inte

Re: [sqlite] Transactions and sqlite3_last_insert_rowid

Dennis Cote wrote: What happens to the ROWID when the transaction is rolled back? Is it as if the record with that ROWID was deleted? Yes If I understand it correctly, connection C1 can do an INSERT, get ROWID 4, C2 does an INSERT, gets 5, and commits, and then C1 commits, with its 4; if C

Re: [sqlite] Transactions and sqlite3_last_insert_rowid

Michael Ekstrand wrote: [EMAIL PROTECTED] wrote: The ROWID is generated after the BEFORE triggers fire and before the row is inserted. OK, I think I'm getting it. The INSERT statement generates the ROWID, fires triggers, then inserts the row. When the transaction is committed, all that

Re: [sqlite] Transactions and sqlite3_last_insert_rowid

[EMAIL PROTECTED] wrote: The ROWID is generated after the BEFORE triggers fire and before the row is inserted. OK, I think I'm getting it. The INSERT statement generates the ROWID, fires triggers, then inserts the row. When the transaction is committed, all that is committed; when the tran

Re: [sqlite] Transactions and sqlite3_last_insert_rowid

Michael Ekstrand <[EMAIL PROTECTED]> wrote: > Will Leshner wrote: > > On 4/17/06, Michael Ekstrand <[EMAIL PROTECTED]> wrote: > > > >> So, if someone could enlighten me as to the defined behavior of > >> sqlite3_last_insert_rowid with regards to transactions, I would be most > >> grateful. > > >

Re: [sqlite] Transactions and sqlite3_last_insert_rowid

On 4/18/06, Michael Ekstrand <[EMAIL PROTECTED]> wrote: > Now, who got the "next" ROWID? Conn 1 or Conn 2? What did > sqlite3_last_insert_rowid() return to Conn 1? sqlite3_last_insert_rowid() can only return the last rowid of the current connection. It can't return the last rowid of some other c

Re: [sqlite] Transactions and sqlite3_last_insert_rowid

Will Leshner wrote: On 4/17/06, Michael Ekstrand <[EMAIL PROTECTED]> wrote: So, if someone could enlighten me as to the defined behavior of sqlite3_last_insert_rowid with regards to transactions, I would be most grateful. The last insert id is a property of a connection. So there is no way th

Re: [sqlite] Transactions and sqlite3_last_insert_rowid

On 4/17/06, Michael Ekstrand <[EMAIL PROTECTED]> wrote: > So, if someone could enlighten me as to the defined behavior of > sqlite3_last_insert_rowid with regards to transactions, I would be most > grateful. The last insert id is a property of a connection. So there is no way that one connection

[sqlite] Transactions and sqlite3_last_insert_rowid

I'm trying to figure out how sqlite3_last_insert_rowid() interacts with transactions. I've read the thread at http://www.mail-archive.com/sqlite-users@sqlite.org/msg13393.html However, the concern raised in the last message of that thread is exactly my concern, and was never addressed in the cont

Re: [sqlite] Transactions

On Thu, 6 Oct 2005, Jens Miltner wrote: > >Am 05.10.2005 um 13:17 schrieb Christian Smith: > >> On Tue, 4 Oct 2005, Martin Engelschalk wrote: >> >> >>> Hello Christian, >>> >>> thank you, but synchronous is already off. What i aim to avoid is >>> writing the rollback - journal. In order to rollbac

Re: [sqlite] Transactions

Am 05.10.2005 um 13:17 schrieb Christian Smith: On Tue, 4 Oct 2005, Martin Engelschalk wrote: Hello Christian, thank you, but synchronous is already off. What i aim to avoid is writing the rollback - journal. In order to rollback, some additional writing to disk is surely unaviodable. Y

Re: [sqlite] Transactions

On Tue, 4 Oct 2005, Martin Engelschalk wrote: >Hello Christian, > >thank you, but synchronous is already off. What i aim to avoid is >writing the rollback - journal. In order to rollback, some additional >writing to disk is surely unaviodable. You'll have to write your own pager layer, as there

  1   2   >