Forum Moderators: coopster
Thanks
Or you could also just add an extra field or two to your db - a code for 'locked', or a lock id. You'll probably also want to make these locks auto-expire after a certain period of time - minutes or hours - for cases when someone fails to submit changes and just abandons the entry locked. You could put a javascript counter on the page to let the user know how long it's locked. Maybe they could still submit the page when the lock is expired, but the entry hasn't been locked by someone else - maybe not. This second approach might give you more control over the whole locking process.
>> lock a record
hmmm, sounds like windows terminology
recordset == many individual records
we do row locking on some tables with Oracle using select for update
Currently, MySQL supports table-level locking for ISAM, MyISAM, and MEMORY (HEAP) tables, page-level locking for BDB tables, and row-level locking for InnoDB tables.
I have a table with a primary key field named ID with autoincrement and unique.
the way i looked into doing this was by setting up a mysql table of what user is looking at what at what time.
Giving each user about a minute on each record and then "logging them out" of that record, you could set up an iframe or similar that reloads every 10 seconds or so, keeping that record "alive" if the users browser is still using that record.
make sense?
ta,
Hugh
I'd like to lock a record that my users are editing so others can not try to edit it at the same time. Can I do it with a session variable or is there a global variable that I can use.
To set a global variable across all sessions, use the shared memory functions.
It's not the most straightforward thing to do by hand, but there are plenty of PHP classes and modules that will hide the specifics and make it easier. Google. I have a vague memory of finding a decent looking one at ONLamp once.
You might store the MySQL row ID in shared memory, along with the time that it was locked. Subsequent requests check shared memory to see if that ID is locked, and if so punt.
You'll need a mechanism to unlock the record. Definitely when the original user finishes their edits, but you'll want to have a failsafe as well. If you store the lock time like I mentioned, readers can use that time to determine if the original lock has been left idle too long.
I've chosen to use more of a 'checkout' system sort of like CVS, albeit a lot less sophisticated. Basically, when someone calls up a record, I throw in the timestamp for the moment it was called up as a hidden field. Then when the user "commits" changes, it checks to see if the record has been edited in the meantime and then displays the fields that conflict and gives the user a chance to decide which version to accept or to edit and combine the two versions manually.
So far this has worked pretty well (it's meant to roughly mimic the MS Access synchronization function, which it seems to do fairly well). If there were lots of users editing the same record at once, it would be a nightmare. In our case we have few users and many records, so it's not a problem.
cheers,
hughie
