# `callAllIdChid` (procedure)


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

## Parameters

| # | Mode | Name | Type |
|---|---|---|---|
| 1 | IN | `p_sParentId` | `varchar(50)` |
| 2 | IN | `p_sParentIdAllId` | `longtext` |

## Body

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

## Narrative

**Business context:** Generalised, depth-unbounded version of the `gdsmodule.sAllId` rebuild — descends the module tree under any given parent and writes `sAllId = '<parent's sAllId>-<self sId>'` to every descendant. Whereas `callAllId` hard-codes the three-level pattern, this one uses recursion (`max_sp_recursion_depth=10`), so it could in principle support deeper trees if any were configured.

**What it does:** opens a cursor over `gdsmodule` rows whose `sParentId = p_sParentId`. For each child: updates `sAllId` to the concatenated path, counts its own children, and if any exist recurses (`CALL callAllIdChid(p_sId, newPath)`). Single-shot tree walk seeded by the caller with a root `sId` and its `sAllId` prefix.

**Invocation:** Status: appears orphaned. No caller found in any channel (form-master, gdsmodule hooks, other routines with a `(` invocation, xly-src grep — the two matches against sibling procs are substring artefacts of `callAllIdChidVisible`). Live module-tree maintenance ships through `callAllId` (the flat three-level variant) — this recursive version was likely written as a fallback for deeper trees that never materialised. Candidate for maintainer audit / deletion.