RE: [PEAR] Database problem

the problem you have described is a classic database issue: concurrency control. The lost updates problem you described is one of the reasons why lots of people pay lots of money to use Oracle/SQL server/etc. When person number one does a select to get the record for display, change the sql to a SELECT ... FOR UPDATE command, which locks the affected table and/or rows. How this works depends on the rdbms you are using. take a look at the documentation for your rdbms. in mysql, using the traditional myISAM table types, which only support atomic operations, you are locking the whole table, which means person number 2 can't even do a select until person 1 releases the lock. with postgresql, and with innodb table types in mysql, you have more flexibility, in that you can do row-level locking. I sense this is getting fairly far off topic for this list . . . Justin Simpson --------------------------------- When two people read the same database record out and have it displayed in their 'browser. Then person one makes changes and submits it back to the database - updating the row. Then person number 2 makes changes to his (now out of date) copy and submits it back to the database, effectively overwriting the update done by the other person! Any ideas or experience with such a problem? My first idea was to have a field for every row in every table which holds a version number - this gets incremented when somebody writes an update back over it. Before writing over it the version number of the data to be written and the version number of the existing record in the dbase are compared.