# `sp_cursor_CardEdit` (procedure)


- **Type:** PROCEDURE
- **Deterministic:** NO
- **SQL data access:** CONTAINS SQL

## Parameters

| # | Mode | Name | Type |
|---|---|---|---|
| 1 | IN | `sBrId` | `varchar(100)` |
| 2 | IN | `sSuId` | `varchar(100)` |
| 3 | OUT | `sCode` | `int` |
| 4 | OUT | `sReturn` | `varchar(4000)` |

## Body

_Body is not pre-cached. To inspect: `mysql --defaults-file=~/.my.cnf -e 'SHOW CREATE PROCEDURE `sp_cursor_CardEdit`'`._

## Narrative

**Business context:** Developer maintenance script — iterates every `elematerials` row with `iAssort<3` (raw-material / 原料 / 半成品 assortment levels) and replays the per-row card-edit recompute by calling `Sp_elematerials_AfterUpdateCard_Edit(sId)`. Effectively a one-shot "rebuild material cards" job.

**What it does:** Declares `Cur_Slave` over `SELECT A.sId FROM elematerials A WHERE iAssort<3`, opens it, counts the rows into `Cur_Slave_Num`, then while-loops `FETCH ... INTO p_sId` and calls `Sp_elematerials_AfterUpdateCard_Edit(p_sId)` for each. No date/tenant filter, no batching. Note: declared OUT params `sCode`/`sReturn` are never written.

**Invocation:** Status: appears orphaned. No caller found in any channel — no form-master binding, no `gdsmodule` hook, no other routine references this name, no xly-src reference. The `sp_cursor_*` family (this proc, `sp_cursor_CardEdit1`, `sp_cursor_test`, `sp_cursor_test1`) reads as developer rebuild scripts — call manually when a code change to `Sp_elematerials_AfterUpdateCard_Edit` needs to be applied retroactively. Candidate for cleanup.
