>Jay Sprenkle wrote:
>The transaction doesn't seem any different than a snapshot of the
>database that you can restore to. I just wondered why there were two
>methods of doing the same thing.
Only in a single user/single thread case are they the same thing. With
Sqlite that might always be
> A transactions is exactly like the original poster stated it.
>
> Assuming all Update, Select, Insert Commands are Atomic. A transaction
> allows the user to group a bunch of commands together and state they should
> be considered atomic, whereas if there is "a failure", then none of them are
lite.org
Subject: Re: [sqlite] Does sqlite really support transaction?
>
> > MySql works like you described.. Frankly im surprised Postgres doesn't
.
> > Id imagine there must be a "continue trnasaction" command or something.
>
> You can define a 'savepoint' insid
>
> > MySql works like you described.. Frankly im surprised Postgres doesn't .
> > Id imagine there must be a "continue trnasaction" command or something.
>
> You can define a 'savepoint' inside a transaction. If something goes
> wrong you roll back to the savepoint and continue from there.
>
12, 2005 12:25 PM
> To: sqlite-users@sqlite.org
> Subject: RE: [sqlite] Does sqlite really support transaction?
>
>
>
>>> This isn't an SQLite thing either... All databases work
>>
>>this way, as
>>
>>>far as I'm aware.
>>>
>>>
commands with the command isqlite program, the commands can just
keep executing.
> -Original Message-
> From: John Buck [mailto:[EMAIL PROTECTED]
> Sent: Thursday, May 12, 2005 12:33 PM
> To: sqlite-users@sqlite.org
> Subject: RE: [sqlite] Does sqlite really supp
nt: 12 May 2005 17:12
To: sqlite-users@sqlite.org
Subject: RE: [sqlite] Does sqlite really support transaction?
*** WARNING ***
This mail has originated outside your organization,
either from an external partner or the Global Internet.
Keep this in mind if you answer this me
> > This isn't an SQLite thing either... All databases work
> this way, as
> >far as I'm aware.
> >
> >
> Postgres refuses to process any further sql statements in a
> transaction
> after an error occurs with
> one of the sql statements.
Heh. I should have said that "all databases
, May 12, 2005 11:26 AM
To: sqlite-users@sqlite.org; Jay Sprenkle
Subject: Re: [sqlite] Does sqlite really support transaction?
Here is the problem. My external program builds sql
script and places into file my_script.sql
Then I execute statement "sqlite3 my_db <
my_script.sql" as a sys
Thomas Briggs wrote:
A transaction is a way to make a group of things that happens atomic,
but an SQL statement that generates an error doesn't really make
anything happen, so it has no impact on the transaction itself or any of
the other actions within it. That kinda the whole point, in a way
Jay Sprenkle
> Subject: Re: [sqlite] Does sqlite really support transaction?
>
> Here is the problem. My external program builds sql
> script and places into file my_script.sql
> Then I execute statement "sqlite3 my_db <
> my_script.sql" as a system call fro
Here is the problem. My external program builds sql
script and places into file my_script.sql
Then I execute statement "sqlite3 my_db <
my_script.sql" as a system call from my external
program. I can check result of execution this
statement and it always returns 0 (success) regardless
of actual
Any return other then 0 from the API function you use to exec your SQL
statement is a fail.
--
JB
-Original Message-
From: Vladimir Zelinski [mailto:[EMAIL PROTECTED]
Sent: Thursday, May 12, 2005 10:31 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Does sqlite really support
Vladimir,
When you execute individual statements and sqlite3_step or sqlite3_exec
returns an error code you should execute a 'ROLLBACK' in stead of a
'COMMIT'. So the logic is:
exec "BEGIN"
perform a bunch of statements
if(all statements successful)
exec "COMMIT"
else
exec "ROLLBACK"
14 matches
Mail list logo
