The point of a transaction is that the update is performed
temporarily, and the changes are visible only within the scope of the
transaction. Once you call commit, the changes are visible to all.
This way one can do a sequence of updates, and mostly ensure that
either all succeed, or no changes are committed to the database.
As an aside, my most recent column for RBD shows how to leverage Rb
memory management with a transaction object to ensure that rollbacks
are always performed unless you commit explicitly.
Charles Yeomans
On Dec 6, 2006, at 11:26 AM, <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]> wrote:
Do you not have to do a "db.commit" to add the update?
I assume the select is to build a recordset.
Regards
From: Charles Yeomans <[EMAIL PROTECTED]>
Date: 2006/12/05 Tue PM 03:57:39 EST
To: REALbasic NUG <[email protected]>
Subject: transactions in REALSQLDatabase
Suppose I have a REALSQLDatabase transaction having the following
form.
UPDATE
SELECT
UPDATE
COMMIT
Should the SELECT statement see the effect of the UPDATE statement?
It seems like it should.
Charles Yeomans
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
