Ah hang on just thought of a flaw in that - in between the second select,
compare and update is enough time for another user to slip in - so I will
still need some kind of logging.

But it brings me nearer the solution!  I think the solution is a combination
of the 2 - start a transaction do a second select but do the comparision in
SQL, then if all ok then start another transaction do the update do the
update(s) of the joined tables and then commit both transactions - that way
MSSQL will lock the required resources during the transaction (and can't
slip in between the 2 sql queries).

Or not?

Ollie

-----Original Message-----
From: DL Neil [mailto:[EMAIL PROTECTED]]
Sent: 02 February 2002 15:40
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Php-Db ML
Subject: Re: [PHP-DB] Ensuring users don't overwrite each other (NOT a
newbie question)


Ollie,

Probably easier to repeat the 'read' (from the first population of the user
form) - and then do the
comparison(s) in PHP - either way it will a SQL query that must be evaluated
by PHP before the UPDATE is issued.

ie put the interaction in a function and call it from the two locations in
the code! That way you don't have
essentially the same logic implemented in two places (fatal when you come to
modify the code/db).

Regards,
=dn


----- Original Message -----
From: "Oliver Cronk" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; "Php-Db ML" <[EMAIL PROTECTED]>
Sent: 01 February 2002 15:23
Subject: Re: [PHP-DB] Ensuring users don't overwrite each other (NOT a
newbie question)


> Yes thats an interesting idea, and this compare-and-modify-if-unchanged
bit
> would be implemented via SQL IF  statement(s) perhaps?
>
> Thanks
>
> Ollie
>
> "Hugh Bothwell" <[EMAIL PROTECTED]> wrote in message
> news:<[EMAIL PROTECTED]>...
> >
> > "Oliver Cronk" <[EMAIL PROTECTED]> wrote in message
> > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > > Thanks for that answer, you filled in some of the blanks for the table
/
> > > logging solution, but I am now looking at row locking instead of a
> > seperate
> > > table (and then doing things similar to what you outlined).
> >
> > Just a thought - if you have the user form echo a copy of the original
> data
> > back (ie in addition to the modified data), you can compare it to the
> > existing data and warn the user if the data has been changed in the
> interim.
> > You must make the [compare-and-modify-if-unchanged] atomic, but that's
> okay,
> > because it's all in the same script anyway - it becomes reasonable to do
> it
> > as a transaction.
> >
> >
>
>
>
> --
> PHP Database Mailing List (http://www.php.net/)
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> To contact the list administrators, e-mail: [EMAIL PROTECTED]
>
>



-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to