What is Revdb_commit() for anyway?

Bob Sneidar bobs at twft.com
Wed Jan 14 12:33:19 EST 2009


Ok, so I poked around in the MySQL user manual and found the syntax  
for transactions. It seems that if you simply execute an insert or  
update without initiating a transaction, the data goes right into the  
SQL database at that moment. If you intend to do transactional updates  
you have to first initiate a transaction, then commit or rollback  
depending on conditions you encounter in the transaction process, like  
someone else updated a record you were using and you don't want to  
overwrite their data.

That makes sense now. I was used to a system of record locks, and  
table locks and client signing to temporarily prevent updates during a  
"transaction" when I used to use conventional file based database  
systems. This will work just as well, and maybe even better. No more  
having to worry about deadlocks due to crash-to-desktop in the middle  
of a transaction!

Bob Sneidar
IT Manager
Logos Management
Calvary Chapel CM

On Jan 13, 2009, at 1:15 PM, Jan Schenkel wrote:

> --- Bob Sneidar <bobs at twft.com> 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
>>
>
> Of course the database has to support transactions
> (not all databases do - for MySQL you have to use the
> InnoDB engine rather than the MyISAM engine, for
> instance) but it is a very powerful feature.
>
> Suppose you're writing all the database changes
> required for selling an article: you have to add the
> invoice detail line, the invoice header record, the
> article history, the inventory, etc.
> It is vital that either all these changes are applied,
> or none of them are - otherwise you have logical
> errors in your database. With transactions, it's as
> simple as committing at the end of the entire update
> procedure. If your app crashes in the middle, all the
> steps will be rolled back until the previous commit -
> so your data will be okay.
>
> Naturally, this is best combined with an
> ACID-compliant database
> <http://en.wikipedia.org/wiki/ACID> to make sure that
> your database will survive a power cut. SQLite and
> PostgreSQL are free ACID-compliant databases with
> transactions and Rev ships with drivers for them.
>
> 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
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution




More information about the use-livecode mailing list