# `Sp_productionPlanInfo_BtnEventUnChange` (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_productionPlanInfo_BtnEventUnChange`'`._

## Narrative

**Business context:** 生产管理 → 生产计划管理 → 生产排程 — toolbar handler that would clear a `mftproductionplanslave` row's machine assignment, but currently rejects every invocation. The intended action is the same shape as `Sp_productionPlanInfo_BtnEventReturn` (reset `sState=0`, blank `sMachineId`/`sMachineName`) — the executable path is disabled.

**What it does:** After the standard NULL guards and `sProInParam` length check, the proc unconditionally sets `sCode=-1`, `sReturn='不能操作，Sp_productionPlanInfo_BtnEventUnChange！'`, and `LEAVE top` before the real loop runs. The downstream loop (now dead code) would read `bFrozen`/`sState`, refuse frozen or completed rows, and `UPDATE mftproductionplanslave SET sState=0, sMachineId='', sMachineName=''`. Currently it never executes.

**Invocation:** Dispatched dynamically by `GenericProcedureCallServiceImpl.doGenericProcedureCall()` — wired to a 生产排程 form button (no Chinese label captured in `gdsmodule.sChinese`). xly-src ships `script/标版/30100101/schedule/Sp_productionPlanInfo_BtnEventUnChange.sql`. Candidate for maintainer audit — the early-LEAVE looks like a temporary kill-switch.
