List:General Discussion« Previous MessageNext Message »
From:Peter Brawley Date:September 26 2005 5:41pm
Subject:Re: Stored Procedures and Functions
View as plain text  
Justin,

 >I don't have any experience with stored procedures and find the
 >Documentation in the MYSQL manual a bit sketchy or maybe I am just
 >miss reading it. Can any one point me to some documentation that will
 >help with fully understanding Stored Procedures?

 >What I am trying to migrate out of my program code is a procedure to
 >do the following for update commands.

 >1)     Determine that the ID Field and the Last Updated Timestamp Field
 >is still the same as when the data was originally read.

 >2)     If not the same then Raise an error back to the program so It can
 >determine the action.

 >3)     If the same then lock row and perform update.

First, a quibble about the logic. Between the time a row is re-read for
changes and the time you write-lock it, it is possible for another process
to update the row. It would seem sounder to explicitly write-lock it up
front, make your changes, then unlock it. But secondly, LOCK is not
permitted in MySQL stored procs, so if you want to use MyISAM
and LOCK, you have to issue the LOCK outside the sproc, eg

SET GLOBAL log_bin_trust_routine_creators=TRUE;
DROP PROCEDURE IF EXISTS UpdTime;
LOCK TABLES test WRITE;
DELIMITER |
CREATE PROCEDURE UpdTime( IN readid INT, IN newtime TIMESTAMP )
BEGIN
  UPDATE test SET time=newtime WHERE id=readid;
END;
|
DELIMITER ;
UNLOCK TABLES;

or more elegantly, convert the table to InnoDB and use a transaction to 
accomplish
the same effect.

PB
http://www.artfulsoftware.com

-----

Blue Wave Software wrote:

>I don't have any experience with stored procedures and find the
>Documentation in the MYSQL manual a bit sketchy or maybe I am just miss
>reading it. Can any one point me to some documentation that will help with
>fully understanding Stored Procedures? 
>
> 
>
>What I am trying to migrate out of my program code is a procedure to do the
>following for update commands.
>
> 
>
>1)     Determine that the ID Field and the Last Updated Timestamp Field is
>still the same as when the data was originally read.
>
>2)     If not the same then Raise an error back to the program so It can
>determine the action.
>
>3)     If the same then lock row and perform update.
>
> 
>
>Future development of this could extend to remove more out of code to handle
>when the two don't match. The procedure there is 
>
>1)     Compare Original Field Value to Current Value in Memory if the two
>don't match then
>
>2)     IF the Original Field Value and the Current Value Stored in Table
>Match then update Field IF not then raise error and prompt user for action.
>
> 
>
>This may be more information than required, but some one out their might be
>doing similar things that they can point me in the direction of some more
>documentation or even better still a few Example scripts that I can pull
>apart and learn from.
>
> 
>
> 
>
>Regards,
>
>              Justin Elward
>
> 
>
>Blue Wave Software Pty Limited
>
>justin@stripped
>
> 
>
>Ph. +61 2 4320 6090
>
>Fx. +61 2 4320 6092
>
> 
>
>----------------------------------------------------------------------------
>-------------------
>
>DISCLAIMER: 
>
>This message is proprietary to Blue Wave Software Pty Limited (BWS) and is
>intended solely for the use of the individual or individuals to whom it is
>addressed. It may contain privileged or confidential information and should
>not be circulated with out informing BWS prior or used for any purpose other
>than for what it is intended. If you have received this message in error,
>please notify the originator immediately. If you are not the intended
>recipient, you are notified that you are strictly prohibited from using,
>copying, altering, or disclosing the contents of this message. BWS accepts
>no responsibility (except where required under Australian law) for loss or
>damage arising from the use or misuse of the information transmitted by this
>email including damage from virus."
>
>----------------------------------------------------------------------------
>-------------------
>
> 
>
>
>  
>
>------------------------------------------------------------------------
>
>No virus found in this incoming message.
>Checked by AVG Anti-Virus.
>Version: 7.0.344 / Virus Database: 267.11.6/111 - Release Date: 9/23/2005
>  
>

Attachment: [text/html]
No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.11.6/111 - Release Date: 9/23/2005
Thread
Stored Procedures and FunctionsBlue Wave Software26 Sep
  • Re: Stored Procedures and FunctionsPeter Brawley26 Sep
  • Re: Stored Procedures and FunctionsGleb Paharenko27 Sep