Sp_bd_EquipmentLoad (procedure)
PLC数据同步
- Type: PROCEDURE
- Deterministic: NO
- SQL data access: CONTAINS SQL
Parameters
| # | Mode | Name | Type |
|---|---|---|---|
| 1 | IN | sLoginId |
varchar(100) |
| 2 | IN | sBrId |
varchar(100) |
| 3 | IN | sSuId |
varchar(100) |
| 4 | IN | bFilter |
varchar(5000) |
| 5 | OUT | sCode |
int |
| 6 | OUT | sReturn |
longtext |
Body
Body is not pre-cached. To inspect: mysql --defaults-file=~/.my.cnf -e 'SHOW CREATE PROCEDURESpbd_EquipmentLoad'._
Narrative
Business context: Header says PLC数据同步, but body is the multi-state equipment-load chart for the 看板管理 / 数字工厂 dashboard — for each machine + plan-state bucket (未排程/排程中/生产中/...), returns the sum of mftproductionplanslave.dHour so the dashboard can stack scheduled vs unscheduled hours.
What it does: Builds dynamic SQL into P_EquipmentLoadChar with one branch per sState value: a fixed '00000000' synthetic machine for sState=0 (未排程) lines, then per-sMachineId aggregates for sState IN (1,2,3,…) joined to elemachine.sMachineName under the current sBrId/sSuId. Emits the rolled-up rows as JSON for the chart.
Invocation: No install script for this exact name under xly-src/script/标版/30100101/ (only the _1 short-form variant Sp_bd_EquipmentLoad1.sql ships). No form-master sSqlStr, no gdsmodule hook, no other-routine caller, no Java caller. Status: appears orphaned. No caller found in any channel — candidate for maintainer audit. Likely reached only by an external dashboard endpoint or superseded by Sp_bd_EquipmentLoad1.
The dynamic-SQL approach (p_sSql + p_sWhere CONCATs) is unusual for this family — the simpler Sp_bd_EquipmentLoad1 static-SQL fork appears to be the live replacement.