Skip to content

Delete claim

Deleting a claim removes not only the CL_INJURY_CLAIM header row but also every TASK row tied to it, so that no orphaned task records remain once the claim itself is gone. The delete runs under the same optimistic-concurrency contract as an update.

Field Value
Operation ID OP-CE-04
Trigger Save() invoked on a claim object marked for deletion (IsDeleted = True)
Inputs ClaimID, current UpdateNum
Outputs Deleted TASK rows and CL_INJURY_CLAIM row, or an UpdateError broken rule on concurrency conflict
Primary components clsClaimEntry.BeforeDelete, clsClaimEntry.AfterDelete
Entry point Business\SAIF.Business.Claim.Entry\clsClaimEntry.vb

Steps

  1. Delete all tasks tied to the claim. Before the claim header itself is removed, BeforeDelete issues a delete against TASK filtered by ClaimID (TASK).
  2. Bind and execute the header delete. BeforeDelete then builds parameter bindings for ClaimID and UpdateNum and issues the delete against CL_INJURY_CLAIM (SQL-027, CL_INJURY_CLAIM).
  3. Enforce optimistic concurrency. The delete's WHERE clause matches on both ClaimID and the caller-supplied UpdateNum; AfterDelete inspects the rows-affected return value (BR-CE-011).
  4. If RowsAffected <> 1: add an UpdateError broken rule indicating the row was changed or deleted by another user since it was last retrieved.
  5. If RowsAffected = 1: the deletion is considered successful.
  6. Return control to the caller with either a successfully deleted object or the broken-rule collection populated with the concurrency-conflict error.

Process flow

flowchart TD
    Start([Save called on claim<br>marked for deletion]) --> DeleteTasks[Delete all TASK rows<br>for ClaimID]
    DeleteTasks --> DeleteHeader[Delete CL_INJURY_CLAIM<br>WHERE ClaimID and UpdateNum]
    DeleteHeader --> Rows{RowsAffected = 1?}
    Rows -->|No| Conflict([Raise UpdateError<br>broken rule])
    Rows -->|Yes| Return([Return successfully<br>deleted claim])

Failure and edge-case behavior

  • A concurrent update or delete by another session between retrieval and this delete produces a rows-affected value of 0, surfaced as an UpdateError broken rule rather than a silent no-op (BR-CE-011).
  • Task deletion (step 1) and header deletion (step 2) run inside the same data-portal transaction; if the header delete fails the concurrency check, the transaction is expected to roll back the task deletion as well, though no explicit compensating logic was found in clsClaimEntry itself.*
  • No cascade to other child tables (e.g., Online 801 submissions, pharmacy eligibility, work-release status) was found in BeforeDelete; deleting a claim that still has such child rows may be blocked by database foreign-key constraints rather than by application logic.*

Note: Statements marked with * were inferred from code structure, naming conventions, or contextual evidence where direct confirmation was not available in source artifacts.

Sources

  • Business\SAIF.Business.Claim.Entry\clsClaimEntry.vb