Sp_Check_sWare (procedure)

仓库校验

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

Parameters

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

Body

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

Narrative

Business context: 基础设置 → 仓库与库位 → 仓库设置 — empty stub for the warehouse-master delete validator. The proc declares the standard 9-parameter signature with COMMENT '仓库校验' and a top:BEGIN ... END; block but contains no logic — it sets sCode=1, sReturn='' and returns.

What it does: Nothing — placeholder body. Was scaffolded as the pre-delete check for the siswarehouse (or equivalent) master but never filled in, so delete operations on 仓库设置 proceed unconditionally through this hook.

Invocation: Bound to gdsmodule.sDeleteProName on 仓库设置 (sId 192116810113315228291507110) — 基础设置 → 仓库与库位. Dispatched by BusinessBaseServiceImpl.checkUpdate(..., "sDeleteProName") (via the Sp_delete_backwriting chain) before the delete batch commits. Because the body is empty, the hook is effectively a no-op. Candidate for maintainer audit on whether validation logic (e.g., refusing to delete a warehouse with stock) belongs here.