>It doesn't matter if you are in a transaction or not, changing
>rows while inside a fetch loop on the same table may lead
>to problems.
Sorry I was talking of another process doing asynchronous writes. I
didn't understand the warning was towards a single rogue process.
Of course letting the
>
>>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
7 matches
Mail list logo
