# `Sp_change_BtnEventbEnable` (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_change_BtnEventbEnable`'`._

## Narrative

**Business context:** 制造管理 / 产品工艺卡 — button handler for "启用版本号" (enable a 产品工艺更改/product-tech-change version). Flips the linked product-tech slave row to `bEnable=1`, marking the new technology version as the active one for production use.

**What it does:** Parses the standard `sProInParam` JSON envelope (`$.params[*].value[*].sId`). For each master id, executes `UPDATE mftproductchange M JOIN mftproductslave N ON M.sSrcslaveId = N.sId SET N.bEnable = 1 WHERE M.sId = p_sId` (tenant-scoped via `sBrandsId`/`sSubsidiaryId`). Nested loops walk both the `params` array and each value's `value` array, so a batch selection of change rows can be activated in a single call.

**Invocation:** Status: appears orphaned. No form-master binding, gdsmodule hook, other-routine caller, or xly-src caller. Naming follows the `Sp_BtnEvent_*` toolbar-button family (lower-case `change` instead of `BtnEvent` prefix), so it is most likely an early-draft or rename-stranded variant of a button action that today is reached through `GenericProcedureCallServiceImpl.doGenericProcedureCall()`. Candidate for maintainer audit — verify whether a toolbar/menu entry still names this proc as `sProcName`.