Sp_Manufacture_ReplaceContent (procedure)

@author:qmj @date:20210706 封存 @describe: 工艺卡批量修改色标

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

Parameters

#	Mode	Name	Type
1	IN	sProInParam	varchar(10000)
2	IN	sMakePerson	varchar(100)
3	IN	sBrId	varchar(100)
4	IN	sSuId	varchar(100)
5	OUT	sReturn	varchar(1000)
6	OUT	sCode	int

Body

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

Narrative

Business context: 工艺管理 — 工艺卡批量修改色标 (process-card batch-replace of color-mark). The proc's own COMMENT marks it 封存 (sealed/archived) on 2021-07-06 by author qmj. Pre-archival use case: on a selected set of mftproductslave rows, replace sCReserve1 (the color-mark field on the related mftproductcontrol) from one value to another.

What it does: Parses the standard generic-dispatch payload sProInParam ($.params[*].value[*].sSlaveId plus $.changeValue.sSReserve1 / $.sSReserve2). For every passed sSlaveId, joins mftproductslave → mftproductcontrol by sParentId filtered on sBrandsId/sSubsidiaryId, then UPDATE mftproductcontrol SET sCReserve1 = p_sSReserve2 WHERE … LIKE concat('%', p_sSReserve1, '%'). Each change is logged into syslog.

Invocation: Status: appears orphaned and self-marked 封存. No form-master binding, no gdsmodule hook, no other-routine caller, no xly-src reference beyond the install script script/标版/30100101/Sp_Manufacture_ReplaceContent.sql. The sProInParam/sReturn/sCode signature suggests it was once a generic-dispatch button handler. Candidate for maintainer cleanup.