Sp_Calc_sModule (procedure)

@author:zhucx @date:2022.01.02 @describe: 1.PC端-系统设定-开发平台-系统模块-保存自动调用本过程

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

Parameters

#	Mode	Name	Type
1	IN	iFlag	int
2	IN	iTmpCheck	int
3	IN	sFormGuid	varchar(100)
4	IN	sGuid	varchar(100)
5	IN	sLoginId	varchar(100)
6	OUT	sReturn	varchar(4000)
7	IN	sBrId	varchar(100)
8	IN	sSuId	varchar(100)
9	OUT	sCode	int

Body

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

Narrative

Business context: 系统设定 → 开发平台 → 系统模块 — gdsmodule save-side hook per the proc header (PC端-系统设定-开发平台-系统模块-保存自动调用本过程). The intent is to keep cached derivations or downstream metadata consistent when a developer edits a module definition.

What it does: Standard Sp_Calc_s<Code> skeleton: defaults the IN params, validates sGuid against gdsmodule, branches on iFlag. The body uses sTmpReturn for cascaded error capture, suggesting it chains into one or more helper procs after the master flag flip; tables actually touched were not enumerable in this pass (DB connection dropped while reading the full body).

Invocation: Status: appears orphaned. No gdsmodule.sProcName binding (per the schema today), no gdsconfigformmaster reference, no other routine refs, no xly-src grep hits. The header comment claims it's called on module-save but the live bindings do not connect it — likely the live system module save now goes through Sp_Calc_sSm or an in-Java path. Candidate for maintainer audit.