This works "pretty well" in that it does keep the data from being edited concurrently. However, it also results in some data being locked for VERY long periods of time because the lock is explicit (as is the unlock). Sometimes users forget to unlock the data after they are done editing it.
basically the flow is as such:
choose to edit data -> edit the data -> preview the changes -> commit changes and unlock data
some people like to stop at the preview the changes step
others at the edit data step (they get distracted by other work, whatever)
most of the time it doesn't matter. The data that is locked isn't data that needs frequent changes. In fact just recently I went to edit a dataset and it was locked - had been for nine months. We were still seeing the pre-edited version publicly; the edited version was exactly the same. The user had locked it for editing but then never did anything and forgot to cancel the edit or complete it.
99% of the time we do last in wins; its easy and sufficient for almost all of our needs.
>> In most areas of our application though, we don't care about dirty updates, since the fact that the data may have changed would never cause the user to want to reconsider his update.and, just to prove your point, Roland ("In the end, it all depends on your business requirements") we have the reverse...for us, the user MUST be prevented from being able to change (potentially) dirty data. That means "pessamistic locking" (not quite in the ADO-type database sence) and preventing the user from being able to edit a record if someone else has "locked" it.IMHO, this is a painful idea (even though we have to try and implement this). The thing that will beat you every time is the disconnected nature of web applications. I'm quietly confident that this realisation will happen as soon as we try to attempt this in earnist and we'll fall back to what Roland and many others do and compare timestamps et al...someone please prove me wrong....what we have to do:It's a can of worms, Andrew. Take Roland's advice and use (and compare) timestamps...my 2cbarry.b-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Roland Collins
Sent: Friday, 27 May 2005 11:30 AM
To: [email protected]
Subject: RE: [CFCDev] Repost: SQL ConcurrencyThat 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.
In most areas of our application though, we don't care about dirty updates, since the fact that the data may have changed would never cause the user to want to reconsider his update.
In the end, it all depends on your business requirements.
Roland
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Andrew Scott
Sent: Thursday, May 26, 2005 9:17 PMTo: [email protected]
Subject: RE: [CFCDev] Repost: SQL Concurrency
Ok I am working on an application that is a multi user intranet application, the current system works on the basis that last in wins on the storage of the data placed back to the database.
I was wondering what other people do to prevent this, like record locking. I was reading a few articles on MSDN about the 3 types of record locking available, but wanted to know how others approached or dealt with the subject as well.
Any help or further discussion would be great.
Regards
Andrew Scott
Technical Consultant
NuSphere Pty Ltd
Level 2/33 Bank Street
South Melbourne, Victoria, 3205
Phone: 03 9686 0485 - Fax: 03 9699 7976
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Roland Collins
Sent: Friday, 27 May 2005 10:46 AM
To: [email protected]
Subject: RE: [CFCDev] Repost: SQL Concurrency
What particular aspects? SQL concurrency is a pretty large topic, depending on what aspects you're referring to.
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] 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/[email protected] ----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] 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/[email protected] ----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] 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/[email protected] ----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] 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/[email protected] ----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] 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/[email protected] ----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] 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/[email protected]----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] 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/[email protected]
--
[EMAIL PROTECTED]
http://blog.rawlinson.us
If you want Gmail - just ask.
