On Nov 4, 2010, at 1:30 AM, Igor Tandetnik wrote:
> Pavel Ivanov wrote:
>>> Yes. That's precisely the intended use case. Remember though that
>>> the transaction is not really committed until COMMIT statement
>>> runs: if your application crashes or machine loses power,
Pavel Ivanov wrote:
>> Yes. That's precisely the intended use case. Remember though that the
>> transaction is not really committed until COMMIT statement
>> runs: if your application crashes or machine loses power, all changes to the
>> beginning of the transaction are
> Yes. That's precisely the intended use case. Remember though that the
> transaction is not really committed until COMMIT statement runs: if your
> application crashes or machine loses power, all changes to the beginning of
> the transaction are rolled back, not just those since last
jeff archer wrote:
> I am using SQLite from C++ and I have implemented a class to manager nested
> transactions using savepoints. I have currently implemented as a stack of
> transactions such that the first Begin uses BEGIN IMMEDIATE, while subsequent
> levels use SAVEPOINT
I am using SQLite from C++ and I have implemented a class to manager nested
transactions using savepoints. I have currently implemented as a stack of
transactions such that the first Begin uses BEGIN IMMEDIATE, while subsequent
levels use SAVEPOINT T where is a sequentially increasing
Enrique Ramirez
<[EMAIL PROTECTED]> wrote:
> I've been working on DBMS systems for a couple of years now (namely
> MS-SQL and MySQL) and I find SQLite's usage of transactions to be
> quite unique and interesting. I've been reading on different websites
> about them and one particular site (which
Hello to all,
I've been working on DBMS systems for a couple of years now (namely
MS-SQL and MySQL) and I find SQLite's usage of transactions to be
quite unique and interesting. I've been reading on different websites
about them and one particular site (which sadly I can't remember)
confused me a
7 matches
Mail list logo