dc
56025cc052
getdata.sas synthesised _____DELETE__THIS__RECORD_____ itself - it added the column to work.out, hoisted it in front of the PKs, set it to "No" on every row, gave it a No/Yes dropdown in the metadata and forced MAXLEN=3 in maxvarlengths. In the editor that column is a constant: it is only ever "No" on load, and its Yes/No rule is already injected client-side (deleteRecordColumnRule.ts, since #253's vertical-array fix). So the backend was sending a column the client already owns. The editor now creates the column, the same way EDIT_STATUS / dc.row_status is client-only: - getdata.sas no longer emits it (data steps, the outdata hoist, the ctrlOptions dropdown, the maxvarlengths override). - deleteRecordColumn.ts asserts the response does NOT carry the name, then prepends it to COLHEADERS. Everything downstream (DcValidator's rules, columnHeader, headerArray) is keyed off COLHEADERS order, so the delete column is still index 0 and the grid is unchanged. - Every row is seeded to 'No' before the validator or HyperFormula sees it. - A response that does carry the name now throws instead of rendering a table whose delete column would shadow a real column of that name. The throw lands in the existing getdata .catch, which sets getdataError and shows the error state. The name is reserved; the docs note is in the sibling docs PR. The multi-dataset loader (multi-dataset.component.ts) builds its own DcValidator from the same responses, so it goes through the same helper. Mocks updated to the new contract (server + sas9 getdata); postdata, getstagetable and makedata are untouched - they consume or seed the flag legitimately, and the upload contract in excel.md / files.md is unchanged. Verified: client unit tests 570/570, npm run build clean, sasjs lint clean on the changed SAS, sasjs compile -t server succeeds, and against the mocked estate coltype-delete-record.cy.ts 2/2, editor.cy.ts 55/55, excel.cy.ts 23/23 and row-cell-limits.cy.ts 5/5.