Sp_Check_sOsa (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_sOsa'._
Narrative
Business context: Stub post-save validator nominally for 采购到货 (per procedure summary), delegating to Sp_afterSave_sOsa. Body initialises sCode/iFlag/sReturn, then immediately calls Sp_afterSave_sOsa(sGuid, sBrId, sSuId, sCode, sReturn) — no validation logic of its own.
What it does: Forwards (sGuid, sBrId, sSuId, sCode, sReturn) to Sp_afterSave_sOsa inside the top: block; relies on that peer to populate sReturn/sCode.
Invocation: Status: appears orphaned. No gdsmodule.sSaveProName/sSaveProNameBefore/sProcName/sDeleteProName row references it; no form-master sSqlStr ref; no other DB routine calls it; xly-src grep yields no hit (no install script under script/标版/). The matching Sp_afterSave_sOsa exists but this wrapper has no live caller — candidate for maintainer audit.