--- 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
