Sp_afterSave_sAcc (procedure)

质量事故报告存后反写数量

• Type: PROCEDURE
• Deterministic: NO
• SQL data access: CONTAINS SQL

Parameters

#	Mode	Name	Type
1	IN	sGuid	varchar(2000)
2	IN	sBrId	varchar(100)
3	IN	sSuId	varchar(100)
4	OUT	sCode	int
5	OUT	sReturn	varchar(4000)

Body

Body is not pre-cached. To inspect: mysql --defaults-file=~/.my.cnf -e 'SHOW CREATE PROCEDURESpafterSave_sAcc'._

Narrative

Business context: 质量事故报告 (quality-accident report) — thin save-phase wrapper. The Sp_afterSave_s<Code> family is the historic post-save hook tier: each is a 1-line delegator to Sp_saveReturn_s<Code>(..., iFlag=2, ...) (the iFlag=2 phase code signals "after save" for the saveReturn worker, distinguishing it from the audit/反审 paths that pass iFlag=1/0). For _sAcc the worker is Sp_saveReturn_sAcc — meant to re-write quantities on related rows after the accident report is saved.

What it does: Wraps sGuid in double-quotes if not already quoted (the worker expects a JSON-array-style id list) and, when sGuid is non-empty, runs CALL Sp_saveReturn_sAcc(sGuid, sBrId, sSuId, 2, @sCode, @sReturn). Does not propagate @sCode/@sReturn back to its own OUT params (unlike the _sGYKK sibling which does).

Invocation: Status: appears orphaned. No caller found in any channel — no gdsmodule row sets sSaveProName / sCalcProName / sProcName to this name, no form-master sSqlStr references it, no other routine calls it, and grep across xly-src finds no hits. Java BusinessBaseServiceImpl.addUpdateDelBusinessData() dispatches the post-save hook via the form/module's sSaveProName column, but in production that column holds the corresponding Sp_Check_s<Code> name, never Sp_afterSave_s<Code> — candidate for maintainer audit. The wrapper-plus-worker pair is decommissioned legacy.