>
>>The only thing that can bite you is if
>>you are in process of fetching rows from some select statement and you
>>update row that was just fetched or update/insert rows that would have
>>been fetched later by the select statement.
>
> As I understand it, simply wrapping every batch operation
>The only thing that can bite you is if
>you are in process of fetching rows from some select statement and you
>update row that was just fetched or update/insert rows that would have
>been fetched later by the select statement.
As I understand it, simply wrapping every batch operation (Read,
Yes, they are perfectly valid. The only thing that can bite you is if
you are in process of fetching rows from some select statement and you
update row that was just fetched or update/insert rows that would have
been fetched later by the select statement. This is generally a bad
thing to do and
I need a confirmation that these operations (i.e reading back the rows, that
were just modified/inserted while the transaction is occuring) are valid and
will not bite me in the long run.
Pavel Ivanov-2 wrote:
>
> Besides the fact that I don't understand what you have meant by these
> lines:
Besides the fact that I don't understand what you have meant by these lines:
> Select * from table where lookup_key = "ABC"
> append save results to my list.
I don't see anything unusual in your algorithm. What do you want us to
verify (which you cannot verify yourself) and what do you
Hi ,
After reading http://sqlite.org/atomiccommit.html I think I should be able
to do the following without any hiccups:
Begin Transaction
For all tables
Select * from table where lookup_key = "ABC"
for selected rows update certain column
insert new rows with
--
View this message in context:
http://old.nabble.com/Nesting-Read-Transactions-tp27565385p27565385.html
Sent from the SQLite mailing list archive at Nabble.com.
___
sqlite-users mailing list
sqlite-users@sqlite.org
configure claims a default build of SQLite 3.6.22 is threadsafe:
./configure --help
...
--enable-threadsafe build a thread-safe library [default=yes]
...
However a diff between configures of 3.6.19 and 3.6.22 says otherwise:
diff sqlite-3.6.19/configure sqlite-3.6.22/configure
...
sqlite> .import C:\HEAD.txt head;
Error: no such table: head;
Any idea why I'm getting "no such table"?
Hi Phil,
The "dot" commands -- such as .import -- don't require a semicolon terminator,
and the utility is interpreting your trailing semicolon as part of the table
name.
You may also want
> because of the semicolon following the table name in your .import -
> command. Remove it.
Yes, I was just about to reply saying I'd spotted that. Funny how
after half an hour of scratching your head, you post to a mailing list
and then spot it immediately. Thanks and apologies.
Phil Hibbs.
--
Hi,
because of the semicolon following the table name in your .import -
command. Remove it.
Martin
Phil Hibbs wrote:
> I'm doing this in SQLite:
>
> sqlite> .separator tabs
> sqlite> create table head
>...> ( id varchar(10)
>...> , tplnr varchar(20)
>...> , plnal varchar(2)
>
I'm doing this in SQLite:
sqlite> .separator tabs
sqlite> create table head
...> ( id varchar(10)
...> , tplnr varchar(20)
...> , plnal varchar(2)
...> , ktext varchar(40)
...> , arbpl varchar(10)
...> , werks varchar(4)
...> , verwe varchar(1)
...> , vagrp varchar(3)
Hello!
On Friday 12 February 2010 04:40:21 Vasanta wrote:
> All expert Users and Developers:
Do not sent your mails to sqlite-...@sqlite.org! This produce spam for core
developers.
And I can't understand you question. What you want to do?
Best regards, Alexey Pechnikov.
http://pechnikov.tel/
13 matches
Mail list logo
