# `PRO_ERPMERGEBASEGDSMODULE` (procedure)


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

## Parameters

| # | Mode | Name | Type |
|---|---|---|---|
| 1 | IN | `sGdsModuleId` | `varchar(100)` |

## Body

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

## Narrative

**Business context:** Platform — form/module label sync. When a `gdsmodule` row's `sChinese` label (the human-readable form name visible in BACK navigation) changes, this proc rewrites `sChinese` onto every historical row across the three merge-reporting tables that references that form id, so report queries display the current label.

**What it does:** reads `sChinese` from `GDSMODULE` for the given id, then runs `UPDATE` against `ERPMERGEWORKORDER`, `ERPMERGEPRODUCTIONREPORT`, and `ERPMERGESALSALESORDER` for rows whose `sFormId = sGdsModuleId`.

**Invocation:** member of the `PRO_ERPMERGEBASE*` denorm-merge family. Called by `ProDao.proErpMergeBaseGdsModule(map)` via MyBatis CALLABLE mapper `ProMapper.xml`, driven from `ChangeGdsModuleServiceImpl.changeTableData()` after the JMS `CHANGE_GDS_MODULE` consumer detects a `GDSMODULE` row mutation. See [Cache invalidation on metadata change](../../reference/maintainer/cache-invalidation.md).