Hi Shawn! > > If two users access the same page and both make changes -- let's say user #1 > updates first -- then user #2 will see the information entered by user #1 > and the changes that user #2 entered will be lost. Is this correct, it > seems to be how DbForms is working? > Yes, dbforms creates new database connection each time a form is send to the server, so it cannot use any build in database locking mechanisms. What you describe is a typical 'lost update' that can occur if the system does not care about that. The reading of the old value and updating to new value of a row is not part of the same transaction.
I would not recommend to implement any locking mechanisms within dbforms, nobody will know if someone will ever click the update buttons or just shuts down his computer. Instead you could do something like that: - add a new column 'last_update' of type timestamp to the table - automatically set this column to 'now' whenever you update or insert, could be done using interceptors - before you do an update you reread the row again and compare that timestamp value with the one you get from the form or maybe have stored before as a session attribute. If it differs, you know someone else has touched your row in the mean time, you might generate an error... I think that should be possible using interceptors with current dbforms. To include this functionality within dbforms as a standard offer, more work would be needed. It must then also be possible to activate or deactivate this as needed. Another problem of this approach is the need for the extra column. Sometimes you are not allowed to change the database schema to support extra functionality within a frontend. Regards Dirk ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ DbForms Mailing List http://www.wap-force.net/dbforms
