RE: Multi-User Update Problem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I apologise if my explanation caused confusion. What I meant to say was that
the update page will pull down the relative record as chosen by a search
page prior to the update page and then populate the form with that data.
Then when someone submits the form all of the fields will be updated in that
record, even if they haven't changed anything. The problem is that we have
some pages where more than one person has to work on the same record and so
there's always a risk of two people with the same record open at once
overwriting each other's changes.

Thanks very much for your suggestions though.

Andy

-----Original Message-----
From: Norland, Martin [mailto:Martin.Norland@xxxxxxxxxx]
Sent: Monday, 29 November 2004 15:36
To: php-db@xxxxxxxxxxxxx
Subject: RE:  Multi-User Update Problem


-----Original Message-----

>Does anyone know a good way of locking out access to a record on a 
>MySQL database when someone has the update page open? The problem is 
>that we have a local intranet site which is accessed by members of 
>different departments. Now at the moment when someone loads the page 
>all of the data is pulled into the form, and then when they submit, all
>of that data is passed back to the database, including anything they 
>haven't changed.
  <snip>

You should really rethink whether sending all those records is
necessary, or wise.  Is the convenience of mass updates really worth the
headache?

>What we are trying to avoid is situations where for example someone 
>leaves the form open on their computer and goes away for lunch. In the 
>meantime someone else at a different station makes changes to the form.

>Then when the first person comes back from lunch, they submit the form,

>thereby writing over all of the second person's changes with the old 
>data.
  <snip>

My personal opinion on this:
	Any database that's so simple/small that it should have its
entire contents updated every change, should only be managed by a single
person.
	If that isn't an option, then the individuals should be
modifying individual records instead of the entire recordset.  This
means a listing page, and selecting the record (or records, using
checkboxes) to update.  This is where you can easily set your locking,
perhaps with a timestamp that will time out after X minutes, to prevent
users overwriting.

If neither of these are options, you have larger problems then you'll be
able to properly solve in a web environment.  Forcing the browser to
re-display the page every minute [set the href explicitly, not reload,
in case of post/etc.] is something that should at least reduce the
chances of massive overwrite errors.  Not that I particularly approve of
that method :)  It is, however, a relatively functional solution - if
you're stuck with neither of the above as being options.

- Martin Norland, Database / Web Developer, International Outreach x3257
The opinion(s) contained within this email do not necessarily represent
those of St. Jude Children's Research Hospital.

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [PHP Users]     [Postgresql Discussion]     [Kernel Newbies]     [Postgresql]     [Yosemite News]

  Powered by Linux