> > the activity becomes disabled in the db so other teachers cant modify > > the same > > > i am relying on the fact that they hit the submit form to ensure the activity > > becomes active to the next person to > > modify it. > > dangerous.
I disagree. If you use a timestamp and userid identifier when writing the lock to the db you know when the lock was created and by whom. A simple admin interface is all that is needed to release locks on the db and set a non update flag for the user who went to lunch to stop them updating the record when they get back from lunch and maybe even a little message on the action page about the lock timing out and letting them know they have to edit the record again. > > so you're using a yes/no field (or similar) to show the record is being > edited and stop others? > > what happens if they just leave the browser open and have lunch? the > record is still locked... Again an admin interface to release locks as above. > I came across this with a medical practice. the solution then was to > accept that the web is stateless and you shouldn't rely on your users like > this. There ARE solutions (eg: timestamps and checking if any changes from > last time worked for me) but the web is not client/server like a > VisualBasic app... Yes the web is stateless, but it is easy enough to create a system to maintain locks on records through careful coding. Rod --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia http://www.mxdu.com/ + 24-25 February, 2004
