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 <[email protected]> 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
[email protected]
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
_______________________________________________
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
