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 committed.
The confusion lies in the scope that "A Failure" is defined. IE in the Database Engine, or in the Application using the database engine. -- JB -----Original Message----- From: Jay Sprenkle [mailto:[EMAIL PROTECTED] Sent: Thursday, May 12, 2005 7:41 PM To: sqlite-users@sqlite.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' inside a transaction. If something goes > wrong you roll back to the savepoint and continue from there. > > You basically roll back to a known-good point. Sqlite implicitly rolls > back to the state that existed before a problematic statement. Uh.... Then how do they define a transaction? It seems like that's what a transaction is for.
