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, all
>>> changes to th
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 rolled back, not
>> just
> 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 "committed
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 T where is a
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
5 matches
Mail list logo
