That Sybase and MS SQL match on their behavior is no surprise considering their common heritage ;) I suppose MS (and sybase for that matter) hasn't done anything on the transaction support since they've split their code bases.
-----Ursprüngliche Nachricht----- Von: Griggs, Donald [mailto:[EMAIL PROTECTED] Gesendet: Montag, 9. April 2007 19:50 An: sqlite-users@sqlite.org Betreff: RE: [sqlite] SQLite and nested transactions Regarding: "...As Igor pointed out this does not resemble a full implementation of transactions, as nested transactions can be committed and rolled back independently of the outer parent transaction." Nonetheless, it would seem, just from the couple of pages below, that some DB vendors find the less-than-full implementation of nested transactions to be useful for at least some purposes. (I.e., an implementation in which inner transactions do little more than adjust counters. If anything is rolled back, then entire outer transaction is rolled back.) I make no claim to being an expert here -- I'm just a googler. ;-) http://manuals.sybase.com/onlinebooks/group-as/asg1250e/sqlug/@Generic__ BookTextView/53608;pt=53608;uf=0 "Nested transactions You can nest transactions within other transactions. When you nest begin transaction and commit transaction statements, the outermost pair actually begin and commit the transaction. The inner pairs just keep track of the nesting level. Adaptive Server does not commit the transaction until the commit transaction that matches the outermost begin transaction is issued. Normally, this transaction "nesting" occurs as stored procedures or triggers that contain begin/commit pairs call each other." http://msdn2.microsoft.com/en-us/library/ms189336.aspx "SQL Server 2005 Books Online Nesting Transactions Explicit transactions can be nested. This is primarily intended to support transactions in stored procedures that can be called either from a process already in a transaction or from processes that have no active transaction. The following example shows the intended use of nested transactions. The procedure TransProc enforces its transaction regardless of the transaction mode of any process that executes it. If TransProc is called when a transaction is active, the nested transaction in TransProc is largely ignored, and its INSERT statements are committed or rolled back based on the final action taken for the outer transaction. If TransProc is executed by a process that does not have an outstanding transaction, the COMMIT TRANSACTION at the end of the procedure effectively commits the INSERT statements..." [opinions are my own, not necessarily those of my company] ---------------------------------------------------------------------------- - To unsubscribe, send email to [EMAIL PROTECTED] ---------------------------------------------------------------------------- - ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
