On 23 Nov 2013, at 11:35pm, Darren Duncan wrote:
> On 2013.11.23 7:20 AM, Simon Slavin wrote:
>> Had the person who devised SQL thought it through, he'd have thought up
>> savepoints instead of transactions and we wouldn't use transactions at all.
>
> This is an interesting proposal, and makes
On 2013.11.23 7:20 AM, Simon Slavin wrote:
Had the person who devised SQL thought it through, he'd have thought up
savepoints instead of transactions and we wouldn't use transactions at all.
This is an interesting proposal, and makes a lot of sense to me, especially
given that savepoints toda
On 23 Nov 2013, at 8:41am, Igor Korot wrote:
> I
> don't have to use SAVEPOINT/RELEASE in this case.
Savepoints /is/ nested transactions. At least the effect is the same. Had the
person who devised SQL thought it through, he'd have thought up savepoints
instead of transactions and we wouldn
On 2013.11.23 1:31 AM, Clemens Ladisch wrote:
Igor Korot wrote:
If I understand correctly, I can do this (pseudo-code):
BEGIN TRANSACTION;
// some SQL statements
BEGIN TRANSACTION;
sqlite> begin; begin;
Error: cannot start a transaction within a transaction
This scenario will not end up wit
Igor Korot wrote:
> If I understand correctly, I can do this (pseudo-code):
>
> BEGIN TRANSACTION;
> // some SQL statements
> BEGIN TRANSACTION;
sqlite> begin; begin;
Error: cannot start a transaction within a transaction
> This scenario will not end up with with unfinished transaction and I
> do
If I understand correctly, I can do this (pseudo-code):
BEGIN TRANSACTION;
// some SQL statements
BEGIN TRANSACTION;
// some more SQL statements
IF (more SQL statements == SUCCESS )
COMMIT;
END
/ no need to ROLLBACK here, it will be done in the outer transaction
IF( SQL statements == SUCCE
On Jul 25, 2009, at 2:26 AM, Pavel Ivanov wrote:
> First of all in case you've mentioned it will be not nested
> transaction but one transaction including all deletes and it will be
> committed when select statement will be finished.
This was true for a long time. But as of version 3.6.5, behavi
First of all in case you've mentioned it will be not nested
transaction but one transaction including all deletes and it will be
committed when select statement will be finished.
As a second note: it's pretty bad idea to change table which is used
in not yet finished select statement. In SQLite it
Hello,
just a short question:
With the current sqlite version, is it possible to have nested
transactions, e.g.
exec select ... from table
while (fetch row) {
if (criteria)
exec delete from t where ...
}
which means execute some 'select', fetching the resul
On Thu, Jan 01, 2009 at 08:19:01PM -0500, D. Richard Hipp wrote:
> FWIW, nested transactions (in the form of SAVEPOINTs) will appear in
> the next SQLite release, which we hope to get out by mid-January.
Is that going to be 4.0.x then? I'm assuming there will need to be
incompatible file format
> This will be a point release: 3.6.8. There are no
> incompatibilities. An important aspect of our social contract is
> that SQLite continues to be compatible moving forward. There are
> hundreds of millions of SQLite3 databases in the world, and we do
> not want to abandon them.
Software c
On Jan 2, 2009, at 12:28 AM, Chris Wedgwood wrote:
> On Thu, Jan 01, 2009 at 08:19:01PM -0500, D. Richard Hipp wrote:
>
>> FWIW, nested transactions (in the form of SAVEPOINTs) will appear in
>> the next SQLite release, which we hope to get out by mid-January.
>
> Is that going to be 4.0.x then?
D. Richard Hipp wrote:
On Thu, 2005-03-31 at 17:08 -0500, Kervin L. Pierre wrote:
Are there plans for supporting nested transactions
in the future?
No.
Shucks. :)
Instead of calling sqlite3_exec("BEGIN") and sqlite3_exec("END")
directly, put them in a wrapper function that counts the number
of ne
Kervin L. Pierre wrote:
Hello again,
Are there plans for supporting nested transactions
in the future? Would that be a difficult extension
to code ( eg. if one thought they could give it a
try :) )
The current restriction makes it hard to use SQLite
in developing a API eg
exposed_func1()
{
On Thu, 2005-03-31 at 17:08 -0500, Kervin L. Pierre wrote:
> Are there plans for supporting nested transactions
> in the future?
No.
> The current restriction makes it hard to use SQLite
> in developing a API eg
>
> exposed_func1(){
> sqlite3_exec("BEGIN");
> [...do stuff...]
>
Hello again,
Are there plans for supporting nested transactions
in the future? Would that be a difficult extension
to code ( eg. if one thought they could give it a
try :) )
The current restriction makes it hard to use SQLite
in developing a API eg
exposed_func1()
{
sqlite3_exec("BEGIN");
16 matches
Mail list logo