-- -----------------------------------------------------------------------------
-- One-time data fix-up: WI.MWISKILLREQUIREMENT.ENFORCEMENT was populated by a
-- Designer UI picklist (workinstruction.json) using a DIFFERENT numbering than
-- the backend's WiDAL.DTOs.Enforcement enum (Log=0, Warn=1, Block=2):
--   old (broken) picklist:  0=Warn, 1=Block, 2=Log
--   backend enum:           0=Log,  1=Warn,  2=Block
-- So a row saved as "Block" (old key 1) reads back on the backend as "Warn", and
-- a row saved as "Log" (old key 2) reads back as "Block" — the opposite of intent,
-- and safety-relevant since Enforcement=2/Block is a hard execution gate. Found
-- and fixed in the picklist/component code 2026-08-15; this remaps rows already
-- saved under the old numbering to their correct value under the new one.
--
-- Confirmed via live query before writing this: only ENFORCEMENT=1 exists today,
-- on both GB5DEMO (1 row) and TransactionTest (2 rows) — this statement is written
-- generally (all 3 old values) in case other environments have used 0 or 2 too.
-- Single UPDATE with a CASE expression is safe against 3-way rotation collisions —
-- SQL Server evaluates CASE against each row's pre-update value.
-- -----------------------------------------------------------------------------

UPDATE WI.MWISKILLREQUIREMENT
SET ENFORCEMENT = CASE ENFORCEMENT
    WHEN 0 THEN 1   -- old Warn  -> new Warn
    WHEN 1 THEN 2   -- old Block -> new Block
    WHEN 2 THEN 0   -- old Log   -> new Log
    ELSE ENFORCEMENT
END
WHERE ENFORCEMENT IN (0, 1, 2);