RE: [CFCDev] Repost: SQL Concurrency

[Nat Papovich]

Alternately you can "check out" a record/row/object when a user selects it for editing. If another user tries to select it for editing, you disallow it until the previous edit is complete. You'd have to build in lock timeouts in the case of a user just surfing away from the record edit form.   NAT That depends on the requirements of the system.  Largely, plain old DB transactions take care of any concurrency issues we have.  In the rare instance that “dirty” updates are not allowed, we have a dt_updated field in the table in question, which we read and save in a hidden field when populating the “edit” form.  During the update process, we pass this value back into our update procedure.  The update procedure then checks that value against the value stored in the database – if they match, the update is committed.  If they don’t match, we display the new information to the user along with the information they entered and ask them if they still want to commit the changes.  It works pretty well. ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org