# `Sp_MftPlanPhase_BtnEventLockAll` (procedure)

> 生产计划跟进：所有机台计划标识为锁定状态，以便对比实际生产计划


- **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 PROCEDURE `Sp_MftPlanPhase_BtnEventLockAll`'`._

## Narrative

**Business context:** 生产管理 → 生产计划跟进 — "锁定全部" button: freezes every unlocked production-plan slave row across all machines so the planner can subsequently compare the locked baseline against actual execution.

**What it does:** Single mass `UPDATE mftproductionplanslave SET bLock=1, tlock=tStartDate, sLock=p_sMakePerson WHERE bLock=0 AND sBrandsId=sBrId AND sSubsidiaryId=sSuId`. No input parsing — `sProInParam` is ignored. Standard `sReturn`/`sCode` out parameters but the body never sets them on success, leaving them as their default `sCode=1`.

**Invocation:** Dispatched dynamically by `GenericProcedureCallServiceImpl.doGenericProcedureCall()` on the 生产计划跟进 grid's 锁定全部 toolbar button. The Java `SqlServiceImpl.getSqlTemple()` source file carries a literal comment `{"sproName":"Sp_MftPlanPhase_BtnEventLockAll","inMap":"slave.sId"}` documenting the `sBtnContent` JSON shape — actual wiring lives in `gdsmodule.sBtnContent`. xly-src ships `script/标版/30100101/schedule/Sp_MftPlanPhase_BtnEventLockAll.sql` (install).