mysql 自动停止-mysql执行存储过程时自动停止

问题描述

mysql执行存储过程时自动停止

DELIMITER $$

DROP PROCEDURE IF EXISTS generatorDataCopy $$

CREATE PROCEDURE generatorDataCopy(inpid VARCHAR(50),OUT msg VARCHAR(50))
BEGIN

DECLARE err INT DEFAULT 0;
-- 如果出现sql异常,则将err设置为1后继续执行后面的操作
DECLARE CONTINUE HANDLER FOR SQLEXCEPTION SET err=1; -- 出错处理  

SET autocommit = 0;
START TRANSACTION;

INSERT INTO tbl_outhosroom_sendchdom(SCID,PLID,MEID,ECIPUCODE,OUTUCODE,AMOUNT,CURRENTINHOSMARK,DOSE,DOSEUNIT,ECIPEOPERATEDATE,PAYMONEY,UNITPRICE,OUTTIME) SELECT DISTINCT rec.SCID,rec.PLID,rec.MEID,rec.ECIPUCODE,rec.OUTUCODE,rec.AMOUNT,rec.CURRENTINHOSMARK,rec.DOSE,rec.DOSEUNIT,rec.ECIPEOPERATEDATE,rec.PAYMONEY,rec.UNITPRICE,rec.OUTTIME FROM tbl_room_sendchdom rec LEFT JOIN tbl_inhos_medord_exec exec ON rec.meid = exec.meid LEFT JOIN tbl_inhos_medord med ON exec.medordid = med.medordid WHERE med.pid=inpid;
INSERT INTO tbl_outhosroom_recedechdom(RCID,SCID,MEID,PLID,UCODE,OPERUCODE,AMOUNT,CURRENTINHOSMARK,DOSE,DOSEUNIT,PAYMONEY,UNITPRICE,OUTTIME) SELECT DISTINCT rec.RCID,rec.SCID,rec.MEID,rec.PLID,rec.UCODE,rec.OPERUCODE,rec.AMOUNT,rec.CURRENTINHOSMARK,rec.DOSE,rec.DOSEUNIT,rec.PAYMONEY,rec.UNITPRICE,rec.OUTTIME FROM tbl_room_recedechdom rec LEFT JOIN tbl_room_sendchdom send ON rec.scid = send.scid LEFT JOIN tbl_inhos_medord_exec exec ON send.meid = exec.meid LEFT JOIN tbl_inhos_medord med ON exec.medordid = med.medordid WHERE med.pid=inpid;

下面是若干条insert语句......

DELETE rec FROM tbl_inhos_refund_record rec LEFT JOIN tbl_inhos_medord_exec exec ON rec.meid = exec.meid LEFT JOIN tbl_inhos_medord med ON exec.medordid = med.medordid WHERE med.pid=inpid;    

DELETE melist FROM tbl_inhos_medord_list melist LEFT JOIN tbl_inhos_medord med ON melist.medordid = med.medordid WHERE med.pid=inpid;    

下面是若干条delete语句......

IF err=1 THEN
    ROLLBACK;
    SET msg = 'fail';
ELSE
    COMMIT;
    SET msg = 'succ';
END IF;

END$$

DELIMITER ;

这是一个数据搬移的存储过程,因为涉及的表比较多,每个人的数据只能通过人的主键去关联的搬移相应的数据。有些表的数据量比较大,所以在连连续搬移的时候就会出现错误码:2013这个错误。我想问的是需要调整那些参数能解决这个问题啊?

时间: 2024-10-11 07:49:20

mysql 自动停止-mysql执行存储过程时自动停止的相关文章

执行存储过程时ORA-01031错误的解决方法

以下存储过程编译正常,其中的SQL语句在PLSQL执行也正常,但是在存储过程中执行即报告错误:ORA-01031: insufficient privileges. create or replace procedure DBA_REBUILD_INDEX As Begin execute   immediate  'alter index PK_DUBAI_STORAGE_OUT_MANIFEST  rebuild online'; execute   immediate  'alter in

执行存储过程时编码的问题请教!

问题描述 存储过程如下CREATEproceduretb_sptest(@Remarknvarchar(4000)=null)asdeclare@strsqlnvarchar(4000)select@strsql='updatetb_tablesetRemark=N'''+@Remark+'''exec(@strsql)GO代码里SqlParameter参数如下sqlParas[3]=newSystem.Data.SqlClient.SqlParameter("@Remark",Sys

求解:使用EF执行存储过程时出现SqlParameterCollection 中已包含 SqlParameter。错误

问题描述 错误信息"System.ArgumentException"类型的未经处理的异常在EntityFramework.SqlServer.dll中发生其他信息:另一个SqlParameterCollection中已包含SqlParameter.出错代码:using(DbContextBasedb=newDbContextBase()){SqlParameter[]parms={newSqlParameter{ParameterName="tblName",Va

SQL Server联机丛书:执行存储过程

server|存储过程|执行 EXECUTE执行标量值的用户定义函数.系统过程.用户定义存储过程或扩展存储过程.同时支持 Transact-SQL 批处理内的字符串的执行 若要唤醒调用函数,请使用 EXECUTE stored_procedure 中描述的语法.语法执行存储过程:[ [ EXEC [ UTE ] ]     {          [ @return_status = ]             { procedure_name [ ;number ] | @procedure_n

MySQL用户执行存储过程的权限

  MySQL中以用户执行存储过程的权限为EXECUTE 比如我们在名为configdb的数据库下创建了如下存储过程,存储过程的定义者为user_admin use configdb; drop procedure if exists sp_dev_test_user_add; delimiter $$ CREATE DEFINER=`user_admin`@`%` PROCEDURE `sp_dev_test_user_add`( in var_user varchar(30), in var

mysql 创建存储过程时,select语句 like中引用变量如何引用?

问题描述 mysql 创建存储过程时,select语句 like中引用变量如何引用? 附代码: delimiter// DROP PROCEDURE IF EXISTS M_DNAME // CREATE PROCEDURE M_DNAME (MONTH VARCHAR(2)) SELECT INCOME.CID,COUNT(*) COUNTS FROM INCOME WHERE TIME LIKE '______MONTH%'; // delimiter ; 如上 like中的MONTH是变量

java调用存储过程-Java执行删除/创建临时表的存储过程时,获取的影响行数总是-1,求大师指点

问题描述 Java执行删除/创建临时表的存储过程时,获取的影响行数总是-1,求大师指点 如题所述,使用Java代码执行删除.创建临时表的存储过程时总是执行不成功(不报错, 但是获取的影响行数为-1),别的存储过程都可以执行成功,求大师指点啊, 存储过程和Java代码如下: 1.存储过程代码 ALTER PROCEDURE [dbo].[PROC_TEMP] AS BEGIN if object_id('tempdb..##temp') is not null Begin DROP TABLE #

mysql远程代码执行/权限提升漏洞

就我目前测试的情况来看,这个漏洞比较鸡肋,原因有以下两点: 1,使用默认方式安装的mysql,mysql用户并没有配置文件/etc/mysql/my.cnf的所属权限: 2,不关闭selinux或apparmor的话,exp脚本执行是会报错的. legalhackers原文中提到这个漏洞的前提是很多人按照错误的安装指南来进行权限配置,将配置文件的所属用户修改成了mysql.不过貌似漏洞发现者手里还藏了几个更加严重的mysql漏洞,并没有披露. I. VULNERABILITY MySQL <=

MySQL远程代码执行/提取的分析与实践

0x00 背景 2016年9月12日,国外安全研究人员Dawid Golunski发布安全公告发现了MySQL的一个可被远程代码执行/权限提升的漏洞(CVE-2016-6662).笔者在研究了原报告后,做了如下分析和实践. 0x01 分析 漏洞披露原址: http://legalhackers.com/advisories/MySQL-Exploit-Remote-Root-Code-Execution-Privesc-CVE-2016-6662.html 影响范围 (漏洞作者9月16日的最新更