If you are worried about concurrency. you could add a TIMESTAMP field to your tables. It works like this. When you read the record you also read the TIMESTAMP value of the last time the record was updated. When you attempt to commit your changes into the database, compare that datetime to the one currently in the record. If it doesn't match, you know that someone (or something) already changed the record since you started reading it.

There are several ways to detect the change: an UPDATE of 0 records or - a transaction wrapped around a read check of the current date followed by an update statement (InnoDB) or - a LOCK/UNLOCK wrapper around a read check of the date with UPDATE.

How you handle edit conflicts is rather application specific. Your options can be summarized as: 1) Forget the changes you are attempting to make and start over with the new information 2) Merge your changes with those already made (requires field by field comparisons) 3) Overwrite the existing changes with your changes.

I concur with James, I don't databind any elements. I found that database automation only works reliably for the most trivial of cases and I firmly believe that I have saved time by constructing my own SQL statements. Not only do I *know* that it will be an optimal statement, I won't have to worry too much about a component upgrade automagically writing platform specific statements because it's trying to optimize for MS Access or MS SQL Server and not MySQL.

My recommendation too, use the connections and recordsets for reading data and manage your own inserts and updates through direct SQL statements.