It's not just that the set of updates are deferred; but if the database
product provides 'true' transaction support, they should stand or fall
together. Either they'll all succeed, or none.
The general idea is that sometimes a series of changes to a database represent
a single logical transaction. The classic example is if you want to move some
money from Alice's account to Bob's: you might update the record for Alice's
account to have $100 less, and update the record for Bob's account to have
$100 more. That will normally have to be at least two updates; but you want t
o regard it as a single transaction. If for some reason there is an error
when you come do to one of these updates, without transaction support, you're
left in a dodgy situation: either $100 has vanished from the system
altogether: or Alice still has her $100, and Bob's got a bonus. By wrapping
the two queries in a transaction, you ensure that doesn't happen. A 'proper'
RDBMS should guarantee this - even if it's not an internal error (Alice's
record isn't there, or the table is locked), even if there's a power cut
halfway through, the database (if it's not corrupted altogether!) will be in
one situation or another.
- Ben
Bob Sneidar wrote:
Ohhh, so let me see if I get it. I issue a series of update statements,
but the data is not actually in the database yet so another user
querying the database for those records would see what the data "used to
be" until I issue a a revdb_commit()?
I can use that to my advantage I suppose.
Bob Sneidar
IT Manager
Logos Management
Calvary Chapel CM
On Jan 12, 2009, at 2:07 PM, Jan Schenkel wrote:
--- Bob Sneidar <[email protected]> wrote:
Hi all.
I have always been a bit confused at this. So far as
I can tell, I
cannot get data back INTO a cursor, I can only read
data FROM the
cursor. In order to write data back to the database,
I have to execute
an SQL query. So what is Revdb_commit() for? Commit
what? I just wrote
the data directly to the SQL database in a query
didn't I?
Or am I mistaken about the ability to write data
back to a cursor?
Bob Sneidar
The revdb_commit function isn't meant for committing
changes to cursors - revdb cursors are by default
read-only; though I think if used with Valentina
Server and the VXCMD you can have read-write cursors,
but I digress.
It is meant for committing transactions. Depending on
the database, all the INSERT, UPDATE and DELETE
statements are each seen as a separate transaction, or
will be considered one giant transaction until you
effectively call revdb_commit or revdb_rollback.
Jan Schenkel.
Quartam Reports & PDF Library for Revolution
<http://www.quartam.com>
=====
"As we grow older, we grow both wiser and more foolish at the same
time." (La Rochefoucauld)
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
