What is Revdb_commit() for anyway?

[Ben Rubinstein]

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 <bobs at twft.com> 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)