Modifying a stored procedure to be transactional should be straightforward, but technicalities often cause roadblocks. One user encountered such an issue when their procedure behaved erratically after adding transaction controls.
The problematic code snippet provided by the user is reproduced below:
<code class="sql">BEGIN DECLARE poid INT; DECLARE EXIT HANDLER FOR SQLEXCEPTION SQLWARNING BEGIN ROLLBACK; END START TRANSACTION; -- ADD option 5 INSERT INTO product_option(product_id,option_id,required) VALUES(insertedProductID,5,0); SET poid = (SELECT LAST_INSERT_ID()); INSERT INTO product_option_value(product_option_id,product_id,option_id,option_value_id,quantity,subtract,price,price_prefix,points,points_prefix,weight,weight_prefix) VALUES(poid,insertedProductID,5,50,0,0,4.99,'+',0,'+',0,'+'); -- ADD option 12 INSERT INTO product_option(product_id,option_id,required) VALUES(insertedProductID,12,1); -- ADD option 13 INSERT INTO product_option(product_id,option_id,required) VALUES(insertedProductID,13,0); COMMIT; END</code>
The user highlighted that the procedure functioned flawlessly before transaction controls were introduced, but afterwards, it prevented even the basic task of saving modifications. The user scoured MySQL documentation and online resources, but no apparent errors could be detected.
An analysis of the provided code revealed two syntactic mistakes:
To resolve the issue, the DECLARE EXIT HANDLER statement should be modified as follows:
<code class="sql">DECLARE EXIT HANDLER FOR SQLEXCEPTION, SQLWARNING BEGIN ROLLBACK; END;</code>
With these corrections, the stored procedure should successfully implement transactionality.
The above is the detailed content of Why is My MySQL Stored Procedure Failing After Adding Transaction Controls?. For more information, please follow other related articles on the PHP Chinese website!